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What is an Operating System? 


• OS is the software that acts an intermediary between 
the user applications and computer hardware. 



Computer System Components 


•Hardware 

• Provides basic computing resources (CPU, memory, I/O devices). 

•Operating System 

• Controls and coordinates the use of hardware among application programs. 

•Application Programs 

• Solve computing problems of users (compilers, database systems, video 
games, business programs such as banking software). 

•Users 

• People, machines, other computers 
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Computer System Organization 


CPU 


disks 

6 = 3(3 


mouse keyboard printer monitor 

/Ml, 




disk 

controller 







grap 

ada 

hies 

Dter 









CPU execution 




xecution sequence: 

• Fetch Instruction at PC 

• Decode 

• Execute (possibly using registers) 

• Write results to registers/mem 

• PC = Next Instruction(PC) 

• Repeat 
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Addr 2 32 -1 



Datal 

DataO 

Inst237 

Inst236 

Inst5 

Inst4 

Inst3 

Inst2 

Instl 

InstO 


AddrO 


PC 

PC 

PC 

PC 


5 




Interrupts 


•Interrupt transfers control to the interrupt service routine 

• Interrupt Service Routine: Segments of code that determine action 
to be taken for interrupt. 

•Determining the type of interrupt 

• Polling: same interrupt handler called for all interrupts, which then 
polls all devices to figure out the reason for the interrupt 

• Interrupt Vector Table: different interrupt handlers will be executed 
for different interrupts 
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Interrupt handling 


• OS preserves the state of the CPU 

•stores registers and the program counter (address of interrupted 
instruction). 

• Incoming interrupts are disabled while another 
interrupt is being processed to prevent a lost 
interrupt. 
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Different types of I/O processing for 
programs 


•Synchronous I/O 

•After I/O is requested, wait until I/O is done. Program will be 
idle. 


•Asynchronous I/O 

•After I/O is requested, control returns to user program 
without waiting for I/O completion. 
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Direct Memory Access (DMA) 


• Used for high speed I/O 
devices able to transmit 
information at close to memory 
speeds. 

• Device controller transfers 
blocks of data from buffer 
storage directly to main 
memory without CPU 
intervention. 
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Process Abstraction 

• Process: an instance of a program, running 
with limited rights 

— Thread: a sequence of instructions within a 
process 

• Potentially many threads per process (for now 1:1) 

— Address space: set of rights of a process 

• Memory that the process can access 

• Other permissions the process has (e.g., which system 
calls it can make, what files it can access) 
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Dual-mode operation 


• Provide hardware support to differentiate between at 
least two modes of operation: 

1 . User mode -- execution done on behalf of a user. 

2. Kernel mode (monitor/supervisor/system mode) -- 
execution done on behalf of operating system. 

• “Privileged” instructions are only executable in the 
kernel mode 

• Executing privileged instructions in the user mode 
“traps” into the kernel mode 

•Trap is a software generated interrupt caused either by an error or 
a user request 
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Providing the Illusion of Separate Address Spaces 
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System Calls 

• User code can issue a syscall, which causes a trap 

• Kernel handles the syscall 
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Enabling Concurrency and 
Protection: Multiplex processes 


Only one process (PCB) active at a time 

□ Current state of process held in PCB: 

■ “snapshot” of the execution and protection environment 

□ Process needs CPU, resources 

Give out CPU time to different processes 
(Scheduling): 

□ Only one process “running” at a time 

□ Give more time to important processes 

Give pieces of resources to different processes 
(Protection): 

□ Controlled access to non-CPU resources 

■ E.g. Memory Mapping: Give each process their own 
address space 


process state 
process number 
program counter 


registers 


memory limits 
list of open files 


• • • 


Process 
Control 
Block M 



Threads 


■ Processes do not share resources well 

□ high context switching overhead 

■ Idea: Separate concurrency from protection 

■ Multithreading: a single program made up of a number of 
different concurrent activities 

m A thread (or lightweight process) 

□ basic unit of CPU utilization; it consists of: 

program counter, register set and stack space 

■ A thread shares the following with peer threads: 

code section, data section and OS resources (open files, signals) 

No protection between threads 

■ Collectively called a task. 

■ Heavyweight process is a task with one thread. 



15 


Single and Multithreaded 
Processes 
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■ Threads encapsulate concurrency: “Active” component 

■ Address spaces encapsulate protection: “Passive” part 

□ Keeps buggy program from trashing the system 
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Thread State 


State shared by all threads in process/addr 
space 

□ Contents of memory (global variables, heap) 

□ I/O state (file system, network connections, etc) 

State “private” to each thread 

□ Kept in TCB = Thread Control Block 

□ CPU registers (including program counter) 

□ Execution stack 

■ Parameters, Temporary variables 

■ return PCs are kept while called procedures are 
executing 



Threads (cont.) 


■ Thread context switch still requires a register 
set switch, but no memory management 
related work! 

■ Thread states - 

■ ready, blocked, running, terminated 

m Threads share CPU and only one thread can 
run at a time. 

■ No protection among threads. 
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Types of Threads 


■ Kernel-supported threads 

■ User-level threads 

■ Hybrid approach implements both user-level 
and kernel-supported threads (Solaris 2). 
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Kernel Threads 


■ Supported by the Kernel 

□ Native threads supported directly by the kernel 

□ Every thread can run or block independently 

□ One process may have several threads waiting on different things 


■ Downside of kernel threads: a bit expensive 

□ Need to make a crossing into kernel mode to schedule 


■ Examples 

□ Windows XP/2000, Solaris, Linux, Tru64 UNIX, 
Mac OS X, Mach, OS/2 
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User Threads 

■ Supported above the kernel, via a set of library calls 
at the user level. 

■ Thread management done by user-level threads library 

□ User program provides scheduler and thread package 

■ May have several user threads per kernel thread 

■ User threads may be scheduled non-preemptively relative to 
each other (only switch on yield()) 

□ Advantages 

■ Cheap, Fast 

□ Threads do not need to call OS and cause interrupts to kernel 

□ Disadv: If kernel is single threaded, system call from any 
thread can block the entire task. 

■ Example thread libraries: 

□ POSIX Pthreads, Win32 threads, Java threads 
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Multithreading Models 


■ Many-to-One 

■ One-to-One 

■ Many-to-Many 
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Many-to-One 

■ Many user-level threads mapped to single 
kernel thread 

■ Examples: 

□ Solaris Green Threads 

□ GNU Portable Threads 
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One-to-One 


■ Each user-level thread maps to kernel thread 



Examples 

□ Windows NT/XP/2000; Linux; Solaris 9 and later 
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Many-to-Many Model 


■ Allows many user level 
threads to be mapped to 
many kernel threads 

■ Allows the operating 
system to create a 
sufficient number of 
kernel threads 

■ Solaris prior to version 9 

. Windows NT/2000 with 
the ThreadFiber package 
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Semantics of fork() and exec() 

• Does fork() duplicate only the calling thread or all threads? 

• Some U NIXes have two versions of fork 

• exec() usually works as normal - replace the running 
process including all threads 



#def ine READ_END 0 
#def ine WRITE_END 1 
int main (void) 

{ 


Ordinary Pipes 

(see full example in the book) 


char write_msg [BUFFER_SIZE] = "Greetings"; 
char read_msg [BUFFER_SIZE] ; 
int fd [2 ] ; 
pid_t pid; 


if (pipe(fd) == -1) { 

/* handle error */ 

} 

pid = fork ( ) ; 

if (pid < 0) { 

/* handle error */ 

} 

If (pid >0) { /* parent process */ 

close (fd [READ_END] ) ; 

write ( fd [WRITE_END] , write_msg, strlen (write_msg) + 1); 
close (fd [WRITE_END] ) ; 

} else { /* child process */ 
close (fd [WRITE_END] ) ; 

read (fd [READ_END] , read_msg, BUFFER_SIZE) ; 
printf ("read %s" , read_msg) ; 
close (fd [READ_END] ) ; 

} 

return 0; 


} 
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Interprocess Communication 


• Processes within a system may be independent or cooperating 

• Cooperating process can affect or be affected by other processes, 
including sharing data 

• Reasons for cooperating processes: 

• Information sharing 

• Computation speedup 

• Modularity 

• Convenience 

• Cooperating processes need interprocess communication (IPC) 

• Two models of IPC 

• Shared memory 

• Message passing 
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Interprocess Communication 

Shared Memory 

• An area of memory shared among the processes that wish 
to communicate 

• The communication is under the control of the processes 
not the operating system. 

• Major issues is to provide mechanism that will allow the 
user processes to synchronize their actions when they 
access shared memory. 

• Synchronization is discussed in great details in Chapter 5. 



Interprocess Communication 

Shared Memory 
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Interprocess Communication 

Message Passing 

• Mechanism for processes to communicate and to synchronize 
their actions 

• Message system - processes communicate with each other 
without resorting to shared variables 

• I PC facility provides two operations: 

• send (message) 

• recei ve(message) 

• The message size is either fixed or variable 



Interprocess Communication 

Message Passing 
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Schedulers 


■ Long-term scheduler (or job scheduler) - 

□ selects which processes should be brought into the ready 
queue. 

□ invoked very infrequently (seconds, minutes); may be slow. 

□ controls the degree of multiprogramming 

■ Short term scheduler (or CPU scheduler) - 

□ selects which process should execute next and allocates 
CPU. 

□ invoked very frequently (milliseconds) - must be very fast 

■ Medium Term Scheduler 

□ swaps out process temporarily 

□ balances load for better throughput 
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Basic Concepts 


• Maximum CPU utilization 
obtained with 
multiprogramming. 

• CPU-I/O Burst Cycle 

• Process execution consists of a cycle 
of CPU execution and I/O wait. 
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CPU Scheduler 


• Selects from among the processes in memory that 
are ready to execute, and allocates the CPU to 
one of them. 

• Non-preemptive Scheduling 

• Once CPU has been allocated to a process, the process keeps 
the CPU until 

• Process exits OR 

• Process switches to waiting state 

• Preemptive Scheduling 

• Process can be interrupted and must release the CPU. 

• Need to coordinate access to shared data 
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Scheduling Criteria 

• CPU Utilization 

• Keep the CPU and other resources as busy as possible 

• Throughput 

• # of processes that complete their execution per time unit. 

• Turnaround time 

• amount of time to execute a particular process from its entry 
time. 
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Scheduling Criteria (cont.) 

• Waiting time 

• amount of time a process has been waiting in the ready queue. 

• Response Time (in a time-sharing environment) 

• amount of time it takes from when a request was submitted until 
the first response is produced, NOT output. 
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Optimization Criteria 

• Max CPU Utilization 

• Max Throughput 

• Min Turnaround time 

• Min Waiting time 

• Min response time 
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Priority Scheduling - Non-preemptive 
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Priority Scheduling - Preemptive 
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• Average waiting time = [0+3+(7+6)+0+0)]/5 = 16/5 = 3.2 msec 

• Average turnaround time = (6 + 11 + 20 + 3 + 5)/5 = 45/5 = 9 msec 

• Average response time (assuming immediate response by a process when 
executed) = (0 + 0 + 7 + 0 + 0)/5 = 1.4 msec 

• CPU utilization = 29 / 35 = 0.83 = 83% 

• Throughput = 5 / 35 = 0.14 #process/msec 
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Critical Section Problem 


Consider system of n processes {p 0 , p v ... p n1 } competing to 
access shared data 

Each process has critical section segment of code 

• Process may be changing common variables, updating 
table, writing file, etc 

• When one process in critical section, no other may be in its 
critical section 

Critical section problem is to design protocol to solve this 

Each process must ask permission to enter critical section in 
entry section, may follow critical section with exit section, 
then remainder section 



Critical Section 


General structure of process P. 


do { 


entry section 


critical section 


exit section 


remainder section 
} while (true); 


Solution: Critical Section Problem - 
Requirements 


• Mutual Exclusion 

• If process Pi is executing in its critical section, then no other 
processes can be executing in their critical sections. 

• Progress 

• If no process is executing in its critical section and there exists 
some processes that wish to enter their critical section, then 
the selection of the processes that will enter the critical section 
next cannot be postponed indefinitely. 

• Bounded Waiting 

• A bound must exist on the number of times that other 
processes are allowed to enter their critical sections after a 
process has made a request to enter its critical section and 
before that request is granted. 



Solution: Critical Section Problem - 
Requirements 


• Assume that each process executes at a 
nonzero speed. 

• No assumption concerning relative speed of the 
n processes. 



Algorithm 1 


• Shared Variables: 

• int turn = 0; 

• (turn == i) means that Pi can enter its critical section 

• Process Pi 

do { 

while (turn == j) ; 

critical section 
turn = j ; 

remainder section 
} while (true) ; 


Satisfies mutual exclusion, but not progress. 



Algorithm 4 


• Combined Shared Variables of algorithms 1 and 2 

• Process Pi 

do { 

flag[i] = true; 
turn = j ; 

while (flag[j] && turn == j) ; 

critical section 
flag[i] = false; 

remainder section 
} while (true) ; 

YES!!! Meets all three requirements, solves the critical section 
problem for 2 processes. 

This is called the “Peterson’s solution”. 



Synchronization Hardware 


Many systems provide hardware support for implementing the 
critical section code. 

Solutions based on idea of locking 

• Protecting critical regions via locks 
Uniprocessors - could disable interrupts 

• Currently running code would execute without preemption 

• Generally too inefficient on multiprocessor systems 

- Operating systems using this not broadly scalable 

Modern machines provide special atomic hardware instructions 

- Atomic = non-interruptible 

• Either test memory word and set value 

• Or swap contents of two memory words 



Solution to Critical-section Problem Using Locks 


do { 

acquire lock 

critical section 
release lock 

remainder section 
} while (TRUE) ; 



test and set Instruction 


Definition: 

boolean test_and_set (boolean *target) 
{ 

boolean rv = * target; 

* target = TRUE; 
return rv: 

} 

1. Executed atomically 

2. Returns the original value of passed parameter 

3. Set the new value of passed parameter to “TRUE”. 



Solution using test_and_set() 


Shared Boolean variable lock, initialized to FALSE 
Solution: 

do { 

while (test_and_set ( &lock) ) 

; /* do nothing */ 

/* critical section */ 
lock = false; 

/* remainder section */ 


} while (true) ; 



Semaphore 


• Semaphore S - integer variable (non-negative) 

• used to represent number of abstract resources 

• Can only be accessed via two indivisible (atomic) operations 

wait (S): while (S <= 0); 

S-; 

signal (S): S++; 

• P or wait used to acquire a resource, waits for semaphore to 
become positive, then decrements it by 1 

• V or signal releases a resource and increments the semaphore 
by 1 , waking up a waiting P, if any 

• If P is performed on a count <= 0, process must wait for V or 
the release of a resource. 

P Q:“proberen” (to test) ; V() “verhogen” (to increment) in Dutch 



Example: Critical Section for n 
Processes 


• Shared variables 

semaphore mutex; 
initially mutex = 1 

• Process P, 

do { 

wait (mutex) ; 

critical section 
signal (mutex) ; 

remainder section 


} while (true) ; 



Semaphore as a General 
Synchronization Tool 


• Execute B in Pj only after A execute in Pi 

• Use semaphore flag initialized to 0 

• Code: 

Pi Pj 


A 

sign a /(flag) 


wait(flag) 

B 



Classical Problems of 
Synchronization 


• Bounded Buffer Problem 

• Readers-Writers Problem 

• Dining-Philosophers Problem 



Readers- Writers Problem 




• Two classes of users: 


• Readers - never modify database 

• Writers - read and modify database 

• Is using a single lock on the whole database sufficient? 


Readers- Writers Problem 



• Two classes of users: 


• Readers - never modify database 

• Writers - read and modify database 

• Is using a single lock on the whole database sufficient? 

• Like to have many readers at the same time 

• Only one writer at a time 


Readers- Writers Problem 


• Shared Data 

• Data set 

• Semaphore rw_mutex initialized to 1 

• Semaphore mutex initialized to 1 

• Integer read_count initialized to 0 

• The structure of a writer process 

do { 

wait (rw_mutex) ; 

/* writing is performed */ 

signal (rw_mutex) ; 

} while (true) ; 



Readers- Writers Problem 


• The structure of a reader process 

do { 

wait (mutex) ; 
read_count++ ; 
if (read_count == 1) 

wait (rw_mutex) ; 

signal (mutex) ; 

/* reading is performed */ 


wait (mutex) ; 

read count--; 

if (read_count == 0) 

signal (rw_mutex) ; 

signal (mutex) ; 

} while (true) ; 



Monitors 


• A high-level abstraction that provides a convenient and effective 
mechanism for process synchronization 

• Abstract data type, internal variables only accessible by code within the 
procedure 

• Only one process may be active within the monitor at a time 

• But not powerful enough to model some synchronization schemes 

monitor monitor-name 
{ 

// shared variable declarations 
procedure Pi (...) { ... . } 

procedure Pn (...) { } 

Initialization code (...) { ... } 

} 

} 



Schematic view of a Monitor 






Condition Variables 


condition x, y; 

Two operations are allowed on a condition variable: 

• x . wait () - a process that invokes the operation is 
suspended until x . signal ( ) 

• x . signal ( ) - resumes one of processes (if any) that 
invoked x . wait () 

- If no x . wait ( ) on the variable, then it has no effect on the 
variable 



Monitor with Condition Variables 






Condition Variables Choices 


If process P invokes x . signal ( ) , and process Q is suspended in 
x . wait ( ) , what should happen next? 

• Both Q and P cannot execute in parallel. If Q is resumed, then P 
must wait 

Options include 

• Signal and wait - P waits until Q either leaves the monitor or it 
waits for another condition 

• Signal and continue - Q waits until P either leaves the monitor or it 
waits for another condition 

• Both have pros and cons - language implementer can decide 
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Outline 


■ System Model 

■ Deadlock Characterization 

■ Methods for handling deadlocks 

■ Deadlock Prevention 

■ Deadlock Avoidance 

■ Deadlock Detection 

■ Recovery from Deadlock 



The Deadlock Problem 


■ A set of blocked processes each holding a 
resource and waiting to acquire a resource 
held by another process in the set. 

□ Example 1 

□ Consider two files. PI and P2 each holds exclusive access 
to one file and needs access to the other file. 

□ Example 2 

□ Semaphores A and B each initialized to 1 

PO PI 

wait(A) wait(B) 

wait(B) wait(A) 
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Definitions 


■ A process is deadlocked if it is waiting for an 
event that will never occur. 

Typically, more than one process will be involved in a 
deadlock (the deadly embrace). 

■ A process is indefinitely postponed if it is 
delayed repeatedly over a long period of time 
while the attention of the system is given to 
other processes, 

■ i.e. the process is ready to proceed but never gets the 
CPU. 
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Example - Bridge Crossing 





□ Assume traffic in one direction. 

■ Each section of the bridge is viewed as a resource. 

□ If a deadlock occurs, it can be resolved only if one 
car backs up (preempt resources and rollback). 

■ Several cars may have to be backed up if a deadlock 
occurs. 







System Model 

• System consists of resources 

• Resource types R v R 2 , . . R 

CPU cycles, memory space, I/O devices 

• Each resource type R. has W. instances. 

• Each process utilizes a resource as 
follows: 


• request 

• use 

• release 



Conditions for Deadlock 

Deadlock can arise if four conditions hold simultaneously. 

• Mutual exclusion: only one process at a time can use a 
resource 

• Hold and wait: a process holding at least one resource is 
waiting to acquire additional resources held by other 
processes 

• No preemption: a resource can be released only 
voluntarily by the process holding it, after that process has 
completed its task 

• Circular wait: there exists a set {P Q , P v P n } of waiting 
processes such that P Q is waiting for a resource that is held 
by P v P 1 is waiting for a resource that is held by P 2 , P n1 
is waiting for a resource that is held by P , and P is waiting 
for a resource that is held by P Q . 
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Resource Allocation Graph 


■ A set of vertices V and a set of edges E 

■ V is partitioned into 2 types 

■ P = {PI, P2,...,Pn} - the set of processes in the system 

■ R = {R1, R2,...,Rn} - the set of resource types in the 
system 

■ Two kinds of edges 

■ Request edge - Directed edge Pi — » Rj 

■ Assignment edge - Directed edge Rj — > Pi 



Resource Allocation Graph 

• Process 


• Resource Type with 4 instances 


□ □ 
□ □ 


• P. requests instance of R 


• P. is holding an instance of R. 



□ □ 
□ □ 


R. 

i 
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Graph with no cycles 


/-?i R 3 
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Graph with cycles (but no 
deadlock) 
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Graph with cycles and deadlock 


Hi R 3 
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Basic facts 


■ If graph contains no cycles 

□ NO DEADLOCK 

■ If graph contains a cycle 

□ if only one instance per resource type, then 
deadlock 

□ if several instances per resource type, possibility 
of deadlock. 
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Methods for handling deadlocks 


■ Ensure that the system will never enter a 
deadlock state. 

□ Deadlock prevention 

□ Deadlock avoidance 

■ Allow the system to potentially enter a 
deadlock state, detect it and then recover 

□ Deadlock detection 

□ Deadlock recovery 

■ Ignore the problem and pretend that 
deadlocks never occur in the system; 

□ Used by many operating systems, e.g. UNIX 
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Deadlock Prevention 


Restrain the ways request can be made 

• Mutual Exclusion — not required for sharable 
resources (e.g., read-only files); must hold for 
non-sharable resources 

• Hold and Wait — must guarantee that whenever a 
process requests a resource, it does not hold any other 
resources 

• Require process to request and be allocated all its 
resources before it begins execution, or allow 
process to request resources only when the process 
has none allocated to it. 

• Low resource utilization; starvation possible 
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Deadlock Prevention (cont.) 

• No Preemption - 

• If a process that is holding some resources requests 
another resource that cannot be immediately 
allocated to it, then all resources currently being held 
are released 

• Preempted resources are added to the list of 
resources for which the process is waiting 

• Process will be restarted only when it can regain its 
old resources, as well as the new ones that it is 
requesting 

• Circular Wait — impose a total ordering of all resource 
types, and require that each process requests resources 
in an increasing order of enumeration 
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Deadlock Avoidance 


■ Set of resources, set of customers, banker 

■ Rules 

□ Each customer tells banker maximum number of resources 
it needs. 

□ Customer borrows resources from banker. 

□ Customer returns resources to banker. 

□ Customer eventually pays back loan. 

■ Banker only lends resources if the system 
will be in a safe state after the loan. 
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Deadlock Avoidance 


Requires that the system has some additional a priori 
information available 

• Simplest and most useful model requires that each 
process declare the maximum number of resources of 
each type that it may need 

• The deadlock-avoidance algorithm dynamically 
examines the resource-allocation state to ensure that 
there can never be a circular-wait condition 

• Resource-allocation state is defined by the number of 
available and allocated resources, and the maximum 
demands of the processes 
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Safe state 


• When a process requests an available resource, system 
must decide if immediate allocation leaves the system in a 
safe state 

• System is in safe state if there exists a sequence <P V P 2 , 

P> of ALL the processes in the systems such that for 
each P the resources that P can still request can be 
satisfied by currently available resources + resources held 
by all the P, with j < i 

• That is: 

• If P. resource needs are not immediately available, then 
P. can wait until all P. have finished 

' i 

• When P. is finished, P. can obtain needed resources, 

j i 

execute, return allocated resources, and terminate 

• When P. terminates, P.^. can obtain its needed 
resources, and so on 
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Basic Facts 

• If a system is in safe state => no deadlocks 

• If a system is in unsafe state => possibility of deadlock 

• Avoidance => ensure that a system will never enter an 
unsafe state. 
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Safe, Unsafe, Deadlock State 
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Avoidance Algorithms 


• Single instance of a resource type 

• Use a resource-allocation graph 

• Multiple instances of a resource type 

• Use the banker’s algorithm 
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Resource Allocation Graph 
Scheme 

• Claim edge P. — ► R. indicated that process P may 
request resource R: t represented by a dashed line 

• Claim edge converts to request edge when a process 
requests a resource 

• Request edge converted to an assignment edge when 
the resource is allocated to the process 

• When a resource is released by a process, 
assignment edge reconverts to a claim edge 

• Resources must be claimed a priori in the system 
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Resource Allocation Graph (aka 
Claim Graph) 


R, 
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Unsafe State in Resource 
Allocation Graph 
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Resource Allocation Graph 
Algorithm 

• Suppose that process P. requests a resource R. 

• The request can be granted only if converting the 
request edge to an assignment edge does not result in 
the formation of a cycle in the resource allocation graph 


27 



Banker’s Algorithm 

• Multiple instances 

• Each process must a priori claim maximum use 

• When a process requests a resource it may have to wait 

• When a process gets all its resources it must return them in a 
finite amount of time 
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Data Structures for the Banker’s 
Algorithm 

Let n = number of processes, and m = number of resources types. 

• Available; Vector of length m. If available [/] = k, there are k 
instances of resource type R. available 

• Max; n x m matrix. If Max [i,j] = k, then process P. may request at 
most k instances of resource type R. 

• Allocation; nx m matrix. If Allocation [ij] = /cthen P is currently 
allocated k instances of R. 

j 

• Need; nx m matrix. If Need[i,j\ = k, then P may need k more 
instances of R to complete its task 

Need [ij] = Max[i,J\ - Allocation [ij] 
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Safety Algorithm 

1 . Let Work and Finish be vectors of length m and n, respectively. 
Initialize: 

Work = Available 

Finish [#] = false for / = 0, 1, n- 1 

2. Find an / such that both: 

(a) Finish [#] = false 

(b) Need i < Work 

If no such / exists, go to step 4 

3. Work = Work + Allocation. 

Finish[i] = true ' 

go to step 2 

4. If Finish [i] == true for all /, then the system is in a safe state 
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Resource-Request Algorithm for 

Process P. 

/ 

Request. = request vector for process P.. If Request j \j] = k then 
process 'p. wants k instances of resource type ft. ' 

1 . If Request j < Need j go to step 2. Otherwise, raise error 
condition, since process has exceeded its maximum claim 

2. If Request j < Available, go to step 3. Otherwise P. must wait, 
since resources are not available 

3. Pretend to allocate requested resources to P. by modifying the 
state as follows: 

Available = Available - Request .; 

Allocation = Allocation . + Request 
Need. = Need j - Request.; 

• If safe => the resources are allocated to P. 

i 

• If unsafe => P. must wait, and the old resource-allocation state 
is restored 
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Example of Banker’s Algorithm 


• 5 processes P Q through P 4 ; 

3 resource types: 

A (10 instances), B (5 instances), and C (7 instances) 

• Snapshot at time T Q \ 



Allocation 

Max 

Available 


ABC 

ABC 

ABC 

p 0 

0 1 0 

753 

332 

Pi 

200 

322 


P 2 

302 

902 


P 3 

2 1 1 

222 


P. 

002 

433 
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Example (Cont.) 


• The content of the matrix Need is defined to be Max - Allocation 

Need 
ABC 
P 0 7 4 3 
P, 122 
P 2 6 0 0 
P 3 0 1 1 
P 4 4 3 1 

• The system is in a safe state since the sequence < P v P y P 4> P 2 , P 0 > 
satisfies safety criteria 
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Example: P 1 Request (1,0,2) 

• Check that Request < Available (that is, (1 ,0,2) < (3,3,2) => true 



Allocation Need Available 


ABC 

ABC ABC 

p 0 

0 1 0 

743 230 

p, 

302 

020 

P 2 

302 

600 

P 3 

2 1 1 

0 1 1 

P< 

002 

43 1 


• Executing safety algorithm shows that sequence < P v P 3 , P 4 , P Q , P> 
satisfies safety requirement 

• Can request for (3,3,0) by P 4 be granted? 

• Can request for (0,2,0) by P Q be granted? 
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Deadlock Detection 

• Allow system to enter deadlock state 

• Detection algorithm 

• Recovery scheme 
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Single Instance of Each Resource 
Type 


• Maintain wait-for graph 

• Nodes are processes 

• P. — ► P. if P. is waiting for P. 

i j i v j 

• Periodically invoke an algorithm that searches for a cycle in the 
graph. If there is a cycle, there exists a deadlock 

• An algorithm to detect a cycle in a graph requires an order of n 2 
operations, where n is the number of vertices in the graph 
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Resource-Allocation Graph and 
Wait-for Graph 



f ? 2 R 5 



(a) 


(b) 


Resource-Allocation Graph Corresponding wait-for graph 
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Several Instances of a Resource 
Type 

• Available; A vector of length m indicates the number of available 
resources of each type 

• Allocation; An n x m matrix defines the number of resources of 
each type currently allocated to each process 

• Request; An nx m matrix indicates the current request of each 
process. If Request [#][/] = k, then process P. is requesting k more 
instances of resource type R.. 
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Detection Algorithm 

1 . Let Work and Finish be vectors of length m and n, respectively 
Initialize: 

(a) Work = Available 

(b) For /= 1,2, n, if Allocation. ± 0, then 
Finish#] = false, otherwise, Finish]}] = true 

2. Find an index / such that both: 

(a) Finish]!] == false 

(b) Request j < Work 

If no such / exists, go to step 4 
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Detection Algorithm (Cont.) 

3. Work = Work + Allocation. 

Finish[i] = true ' 

go to step 2 


4. If Finish[i] == false, for some i, 1 < / < n, then the system is 
deadlock state. Moreover, if Finish[i\ == false, then P j is 
deadlocked 


Algorithm requires an order of 0(m x n 2 ) operations to detect 
whether the system is in deadlocked state 



Example of Detection Algorithm 

• Five processes P Q through P 4 ; three resource types A (7 instances), B (2 
instances), and C (6 instances) 

• Snapshot at time T Q \ 


Allocation 

Reauest 

Available 


ABC 

ABC 

ABC 

p 0 

0 1 0 

000 

000 

Pi 

200 

202 


P 2 

303 

000 


P 3 

2 1 1 

1 00 


P 4 

002 

002 



• Sequence <P Q , P 2 , P y P r P > will result in Finish[i] = true for all / 
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Example (Cont.) 

• P 2 requests an additional instance of type C 

Request 
ABC 
P 0 0 0 0 
P, 2 02 
P 2 0 0 1 
P 3 1 0 0 
P 4 0 0 2 

• State of system? 

• Can reclaim resources held by process P Q , but insufficient 
resources to fulfill other processes; requests 

• Deadlock exists, consisting of processes P v P 2 , P 3 , and P 4 
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Detection-Algorithm Usage 

• When, and how often, to invoke depends on: 

• How often a deadlock is likely to occur? 

• How many processes will need to be rolled back? 

- one for each disjoint cycle 


• If detection algorithm is invoked arbitrarily, there may be many 
cycles in the resource graph and so we would not be able to tell 
which of the many deadlocked processes “caused” the deadlock. 


43 



Recovery from Deadlock: Process 
Termination 

• Abort all deadlocked processes 

• Abort one process at a time until the deadlock cycle is eliminated 

• In which order should we choose to abort? 

1 . Priority of the process 

2 . How long process has computed, and how much longer to 
completion 

3. Resources the process has used 

4. Resources process needs to complete 

5. How many processes will need to be terminated 

6. Is process interactive or batch? 
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Recovery from Deadlock: 
Resource Preemption 

• Selecting a victim - minimize cost 

• Rollback - return to some safe state, restart process for that state 

• Starvation - same process may always be picked as victim, 
include number of rollback in cost factor 
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Outline 


■ Background 

■ Logical versus Physical Address Space 

■ Swapping 

■ Contiguous Allocation 

■ Paging 

■ Segmentation 

■ Segmentation with Paging 



Background 


■ Program must be brought into memory and 
placed within a process for it to be executed. 

■ Input Queue - collection of processes on the 
disk that are waiting to be brought into 
memory for execution. 

■ User programs go through several steps 
before being executed. 



Virtualizing Resources 


■ Physical Reality: Processes/Threads share the same 

hardware 

□ Need to multiplex CPU (CPU Scheduling) 

□ Need to multiplex use of Memory (Today) 

■ Why worry about memory multiplexing? 

□ The complete working state of a process and/or kernel is defined 
by its data in memory (and registers) 

□ Consequently, cannot just let different processes use the same 
memory 

□ Probably don’t want different processes to even have access to 
each other’s memory (protection) 



Important Aspects of Memory Multiplexing 


■ Controlled overlap: 

□ Processes should not collide in physical memory 

□ Conversely, would like the ability to share memory when desired (for 
communication) 

■ Protection: 

□ Prevent access to private memory of other processes 

■ Different pages of memory can be given special behavior (Read Only, 
Invisible to user programs, etc) 

■ Kernel data protected from user programs 

■ Translation: 

□ Ability to translate accesses from one address space (virtual) to a 
different one (physical) 

□ When translation exists, process uses virtual addresses, physical 
memory uses physical addresses 



Names and Binding 


□ Symbolic names — > Logical names — ► Physical 
names 

■ Symbolic Names: known in a context or path 

□ file names, program names, printer/device names, user 
names 

■ Logical Names: used to label a specific entity 

□ inodes, job number, major/minor device numbers, process 
id (pid), uid, gid.. 

■ Physical Names: address of entity 

□ inode address on disk or memory 

□ entry point or variable address 

□ PCB address 



Binding of instructions and data to 
memory 

□ Address binding of instructions and data to memory 
addresses can happen at three different stages. 

■ Compile time: 

□ If memory location is known a priori, absolute code can be 
generated; must recompile code if starting location changes. 

■ Load time: 

□ Must generate relocatable code if memory location is not known 
at compile time. 

■ Execution time: 

□ Binding delayed until runtime if the process can be moved 
during its execution from one memory segment to another. 

Need hardware support for address maps (e.g. base and limit 
registers). 



Binding time tradeoffs 


□ Early binding 

□ compiler - produces efficient code 

□ allows checking to be done early 

□ allows estimates of running time and space 

□ Delayed binding 

□ Linker, loader 

□ produces efficient code, allows separate compilation 

□ portability and sharing of object code 

□ Late binding 

□ VM, dynamic linking/loading, overlaying, interpreting 

□ code less efficient, checks done at runtime 

□ flexible, allows dynamic reconfiguration 



Multi-step Processing of a Program for Execution 


■ Preparation of a program for execution 
involves components at: 

□ Compile time (i.e. , “gcc”) 

□ Link/Load time (unix “Id” does link) 

□ Execution time (e.g. dynamic libs) 

■ Addresses can be bound to final values 
anywhere in this path 

□ Depends on hardware support 

□ Also depends on operating system 

■ Dynamic Libraries 

□ Linking postponed until execution 

□ Small piece of code, stub, used to locate 
appropriate memory-resident library routine 

□ Stub replaces itself with the address of the 
routine, and executes routine 



Dynamic Loading 


■ Routine is not loaded until it is called. 

■ Better memory-space utilization; unused 
routine is never loaded. 

■ Useful when large amounts of code are 
needed to handle infrequently occurring 
cases. 

■ No special support from the operating system 
is required; implemented through program 
design. 



Dynamic Linking 


■ Linking postponed until execution time. 

■ Small piece of code, stub, used to locate the 
appropriate memory-resident library routine. 

■ Stub replaces itself with the address of the 
routine, and executes the routine. 

■ Operating system needed to check if routine 
is in already in memory. 



Overlays 


■ Keep in memory only those instructions and 
data that are needed at any given time. 

■ Needed when process is larger than amount 
of memory allocated to it. 

■ Implemented by user, no special support 
from operating system; programming design 
of overlay structure is complex. 



Overlaying 


Ok 





Logical vs. Physical Address Space 


□ The concept of a logical address space that is 
bound to a separate physical address space is 
central to proper memory management. 

■ Logical Address: or virtual address - generated by CPU 

■ Physical Address: address seen by memory unit. 

□ Logical and physical addresses are the same in 
compile time and load-time binding schemes 

□ Logical and physical addresses differ in 
execution-time address-binding scheme. 



Memory Management Unit (MMU) 


■ Hardware device that maps virtual to physical 
address. 

■ In MMU scheme, the value in the relocation 
register is added to every address generated 
by a user process at the time it is sent to 
memory. 

■ The user program deals with logical 
addresses; it never sees the real physical 
address. 



Swapping 


□ A process can be swapped temporarily out of 
memory to a backing store and then brought back 
into memory for continued execution. 

□ Backing Store - fast disk large enough to accommodate 
copies of all memory images for all users; must provide 
direct access to these memory images. 

□ Roll out, roll in - swapping variant used for priority based 
scheduling algorithms; lower priority process is swapped 
out, so higher priority process can be loaded and executed. 

□ Major part of swap time is transfer time; total transfer time 
is directly proportional to the amount of memory swapped. 

□ Modified versions of swapping are found on many systems, 
i.e. UNIX and Microsoft Windows. 



Schematic view of swapping 



Contiguous Allocation 


■ Main memory usually into two partitions 

■ Resident Operating System, usually held in low memory 
with interrupt vector. 

■ User processes then held in high memory. 

■ Single partition allocation 

■ Relocation register scheme used to protect user 
processes from each other, and from changing OS code 
and data. 

■ Relocation register contains value of smallest physical 
address; limit register contains range of logical 
addresses - each logical address must be less than the 
limit register. 



Relocation Register 






Relocation and Limit Registers 



memory 






Fixed partitions 






Contiguous Allocation (cont.) 


■ Multiple partition Allocation 

■ Hole - block of available memory; holes of various sizes 
are scattered throughout memory. 

■ When a process arrives, it is allocated memory from a 
hole large enough to accommodate it. 

■ Operating system maintains information about 

□ allocated partitions 

□ free partitions (hole) 



Contiguous Allocation example 


OS 


OS 

Process 5 


Process 5 

Process 8 



Process 2 


Process 2 


■=> 


OS 


OS 

Process 5 


Process 5 

Process 9 


Process 9 


\ 

i/ 

Process 10 




Process 2 


Process 2 






Dynamic Storage Allocation 
Problem 

□ How to satisfy a request of size n from a list of free holes. 

■ First-fit 

□ allocate the first hole that is big enough 

■ Best-fit 

□ Allocate the smallest hole that is big enough; must search 
entire list, unless ordered by size. Produces the smallest 
leftover hole. 

■ Worst-fit 

□ Allocate the largest hole; must also search entire list. Produces 
the largest leftover hole. 

□ First-fit and best-fit are better than worst-fit in terms of 
speed and storage utilization. 



Fragmentation 


■ External fragmentation 

□ total memory space exists to satisfy a request, but it is 
not contiguous. 

■ Internal fragmentation 

□ allocated memory may be slightly larger than requested 
memory; this size difference is memory internal to a 
partition, but not being used. 

■ Reduce external fragmentation by compaction 

□ Shuffle memory contents to place all free memory 
together in one large block 

□ Compaction is possible only if relocation is dynamic, and 
is done at execution time. 

□ I/O problem - (1 ) latch job in memory while it is in I/O (2) 
Do I/O only into OS buffers. 



Fragmentation example 












Compaction 
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6k 

hole 


job 5 5k 
' hole 



job 6 


5k 

hole 








mcnilor 

job 5 ; 

H job3 \ 

job 6 | 

16k 

hole 



Paging 

■ Logical address space of a process can be 
non-contiguous; 

■ process is allocated physical memory wherever the latter is 
available. 

■ Divide physical memory into fixed size blocks called frames 

□ size is power of 2, 512 bytes - 8K 

■ Divide logical memory into same size blocks called pages. 

□ Keep track of all free frames. 

□ To run a program of size n pages, find n free frames and load 
program. 

■ Set up a page table to translate logical to physical addresses. 

■ Note:: Internal Fragmentation possible!! 



Address Translation Scheme 


■ Address generated by CPU is divided into: 

■ Page number(p) 

□ used as an index into page table which contains base 
address of each page in physical memory. 

■ Page offset(d) 

□ combined with base address to define the physical memory 
address that is sent to the memory unit. 



Address Translation Architecture 
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Example of Paging 
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page table 
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physical 

memory 





Page Table Implementation 


■ Page table is kept in main memory 

■ Page-table base register (PTBR) points to the page table. 

■ Page-table length register (PTLR) indicates the size of page 
table. 

□ Every data/instruction access requires 2 memory accesses. 

■ One for page table, one for data/instruction 

■ Two-memory access problem solved by use of special 
fast-lookup hardware cache (i.e. cache page table in 
registers) 

□ associative registers or translation look-aside buffers (TLBs) 



Translation Lookaside Buffer (TLB) 
(aka Associative Registers) 

Page # Frame # 


Address Translation 
(A, A’) 


■ If A is in TLB, get frame # 

■ Otherwise, need to go to page table for 
frame# 

■ requires additional memory reference 

□ Page Hit ratio - percentage of time page is found 
in TLB. 



Paging hardware with TLB 



physical 

memory 


page table 








Effective Access time 


■ TLB lookup time = 8 time units 

■ Assume Memory cycle time = m time units 

■ Hit ratio = a 

■ Effective access time (EAT) 

□ EAT = (m + e) a + ((2 * m) + £) (1 -a) 



Memory Protection 


■ Implemented by associating protection bits 
with each frame. 

■ Valid/invalid bit attached to each entry in 
page table. 

□ Valid: indicates that the associated page is in the 
process’ logical address space. 

□ Invalid: indicates that the page is not in the 
process’ logical address space. 



Two Level Page Table Scheme 




Two Level Paging Example 


■ A logical address (32bit machine, 4K page size) is 
divided into 

□ a page number consisting of 20 bits, a page offset 
consisting of 12 bits 

■ Since the page table is paged, the page number consists 
of 

□ a 10-bit page number, a 10-bit page offset 

■ Thus, a logical address is organized as (pi ,p2,d) where 

□ pi is an index into the outer page table 

□ p2 is the displacement within the page of the outer page 
table 


Page number 

Page offset 

pi 

P2 

d 


Two Level Paging Example 
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Multilevel paging 


■ Each level is a separate table in memory 

□ converting a logical address to a physical one may take 4 
or more memory accesses. 

□ Caching can help performance remain 
reasonable. 

■ Assume cache hit rate is 98%, memory access time is 
quintupled (100 vs. 500 nanoseconds), cache lookup 
time is 20 nanoseconds 

■ Effective Access time = 0.98 * 120 + .02 * 520 = 128 ns 

■ This is only a 28% slowdown in memory access time... 



Inverted Page Table 


■ One entry for each real page of memory 

■ Entry consists of virtual address of page in real memory 
with information about process that owns page. 

□ Decreases memory needed to store page table 

□ Increases time to search table when a page 
reference occurs 

■ table sorted by physical address, lookup by virtual 
address 

□ Use hash table to limit search to one (maybe few) 
page-table entries. 



Inverted Page Table 
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Inverted Page Table vs. Hashed 
Inverted Page Table 


pid p d 



d 


pid p d 



Figures adopted and modified from: CS162, UC Berkeley, Spring 2004, Discussion #10, by Amir Kamil, Topics: Inverted Page Tables, TLBs 

( https://web.eecs. umich.edu/~akamil/teachina/sD04/040104.Ddf1 


Shared pages 

■ Code and data can be shared among processes 

■ Reentrant (non self-modifying) code can be shared. 

■ Map them into pages with common page frame mappings 

■ Single copy of read-only code - compilers, editors etc.. 

■ Shared code must not necessarily appear in the 
same location in the logical address space of all 
processes 

■ Private code and data 

■ Each process keeps a separate copy of code and data 

■ Pages for private code and data can appear anywhere in 
logical address space. 
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Segmentation 


■ Memory Management Scheme that supports 
user view of memory. 

■ A program is a collection of segments. 

■ A segment is a logical unit such as 

□ main program, procedure, function 

□ local variables, global variables, common block 

□ stack, symbol table, arrays 

■ Protect each entity independently 

■ Allow each segment to grow independently 

■ Share each segment independently 



Logical view of segmentation 



User Space 


Physical Memory 







Segmentation Architecture 


□ Logical address consists of a two tuple 

<segment-number, offset> 

□ Segment Table 

■ Maps two-dimensional user-defined addresses into 
one-dimensional physical addresses. Each table entry has 

□ Base - contains the starting physical address where the 
segments reside in memory. 

□ Limit - specifies the length of the segment. 

■ Segment-table base register (STBR) points to the segment 
table’s location in memory. 

■ Segment-table length register (STLR) indicates the number 
of segments used by a program; segment number is legal if s 
< STLR. 



Segmentation Architecture (cont.) 


□ Relocation is dynamic - by segment table 

□ Sharing 

■ Code sharing occurs at the segment level. 

■ Shared segments must not necessarily have same 
segment number. 

□ Allocation - dynamic storage allocation problem 

■ use best fit/first fit, may cause external fragmentation. 

□ Protection 

■ protection bits associated with segments 

□ read/write/execute privileges 

□ array in a separate segment - hardware can check for 
illegal array indexes. 



Shared segments 
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Segmentation hardware 
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Segmented Paged Memory 


□ Segment-table entry contains not the base 
address of the segment, but the base address of 
a page table for this segment. 

■ Overcomes external fragmentation problem of 
segmented memory. 

■ Paging also makes allocation simpler; time to search for 
a suitable segment (using best-fit etc.) reduced. 

■ Introduces some internal fragmentation and table space 
overhead. 

□ Multics - single level page table 

□ IBM OS/2 - OS on top of Intel 386 

■ uses a two level paging scheme 



MULTICS address translation scheme 


Segment Table Base Register Virtual Address 
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Staff 


• The course will be taught by 

• Ardalan Amiri Sani (ardalan@uci.edu) 
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Teaching Assistants: 

Tiago Muck ( tmuck@ics.uci.edu ) 

Paul Kirth ( pkirth@uci.edu ) 

Jia Chen ( iiac5@ics.uci.edu ) 

Readers: 

Hamid Tavakoli ( seved hat@uci.edu ) 
Aditya Rajendra Joshi ( ioshiar@uci.edu ) 
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Course logistics and details 


Course web page - 

♦ http://www.ics.uci.edu/~ics143 

Discussions - Fridays 1 0:00-1 0:50 a.m, 11-11 :50 a.m 
12-12:50 p.m, ICS 174 

• Pop quizzes 


Course logistics and details 


•Textbook: 

Operating System Concepts -- Ninth Edition 
A. Silberschatz, P.B. Galvin, and G. Gagne 
(Eighth, Seventh, Sixth and Fifth editions, 
and Java Versions are fine as well). 

•Alternate Books 



UMIUllli Uw (KM 


• Operating Systems: Principles and Practice, by T. Anderson and M. Dahlin (second 
edition) 

• Modern Operating Systems, by Tanenbaum (Third edition) 

• Principles of Operating Systems, by L.F. Bic and A.C. Shaw, 2003. 
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Course logistics and details 


•Homeworks and Assignments 

•4 written homeworks in the quarter 

• 1 programming assignment (knowledge of C++ or Java 
required). 

• Handed out at midterm; submit/demo during Finals Week 

• Multistep assignment - don’t start in last week of classes!!! 

• Late homeworks will not be accepted. 

• All submissions will be made using the EEE Dropbox for the 
course 

•Tests 

• Midterm - tentatively Thursday, Week 6 in class 

• Final Exam - per UCI course catalog 
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Grading Policy 


•Homeworks - 30% 

• 4 written homeworks each worth 5% of the final grade. 

• 1 programming assignment worth 10% of the final grade 

•Midterm - 30% of the final grade 
•Final exam - 40% of the final grade 

•Final assignment of grades will be based on a curve. 
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Lecture Schedule 


•Week 1 

• Introduction to Operating Systems, Computer System Structures, 
Operating System Structures 

•Week 2 

• Processes and Threads 

•Week 3 

• Processes and Threads, and CPU Scheduling 

•Week 4 

• Scheduling 

•Week 5 

• Process Synchronization 
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Course Schedule 


•Week 6 

• Deadlocks, Midterm review and exam 

•Week 7 

• Memory Management 

•Week 8 

• Memory Management, Virtual Memory 

•Week 9 

• File Systems Interface and Implementation 

•Week 10 

• I/O Subsystems 
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Office hours 


• Instructor 

• (Tentative) Tuesday 6:45pm-8:15pm (Location TBD) 

• TA’s 

• Thursday 3pm-4:30pm (Location: ICS 424A) 
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Piazza 


• https://piazza.com/uci/sprina2017/ics143a 

• Post questions here. 
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Overview 


•What is an operating system? 

•Operating systems history 

•Computer system and operating system structure 
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What is an Operating System? 
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What is an Operating System? 


•OS is the software that acts an intermediary between 
the user applications and computer hardware. 
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Computer System Components 


•Hardware 

• Provides basic computing resources (CPU, memory, I/O devices). 

•Operating System 

• Controls and coordinates the use of hardware among application programs. 

•Application Programs 

• Solve computing problems of users (compilers, database systems, video 
games, business programs such as banking software). 

•Users 

• People, machines, other computers 
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Abstract View of System 
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Operating system roles 


• Referee 

• Resource allocation among users, applications 

• Isolation of different users, applications from each other 
•Communication between users, applications 
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Operating system roles 


•Illusionist 

• Each application appears to have the entire machine to itself 

• Infinite number of processors, (near) infinite amount of memory, 
reliable storage, reliable network transport 


18 



Operating system roles 


•Glue 

•Libraries, user interface widgets, ... 

• Reduces cost of developing software 
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Example: file systems 


•Referee 

• Prevent users from accessing each other’s files without 
permission 

•Illusionist 

• Files can grow (nearly) arbitrarily large 

• Files persist even when the machine crashes in the middle of 
save 

•Glue 

•Named directories, printf, ... 



OS challenges 
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OS challenges 

•Reliability 

• Does the system do what it was designed to do? 
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OS challenges 


•Availability 

•What portion of the time is the system working? 

• Mean Time To Failure (MTTF), Mean Time to Repair 


23 



OS challenges 

•Security 

• Can the system be compromised by an attacker? 
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OS challenges 

•Privacy 

• Data is accessible only to authorized users 
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OS challenges 


•Performance 

• Latency/response time 

• How long does an operation take to complete? 

•Throughput 

• How many operations can be done per unit of time? 

• Overhead 

• How much extra work is done by the OS? 

• Fairness 

• How equal is the performance received by different users? 

• Predictability 

• How consistent is the performance over time? 
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OS challenges 


•Portability 

• For programs: 

•Application programming interface (API) 

• For the kernel 

• Hardware abstraction layer 
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OS needs to keep pace with 
hardware improvements 



1981 

1997 

2014 

Factor 

(2014/1981) 

Uniprocessor speed (MIPS) 

1 

200 

2500 

2.5K 

CPUs per computer 

1 

1 

10+ 

10+ 

Processor MIPS/$ 

$100K 

$25 

$0.20 

500K 

DRAM Capacity (MiB)/$ 

0.002 

2 

IK 

500K 

Disk Capacity (GiB)/$ 

0.003 

7 

25K 

10M 

Home Internet 

300 bps 

256 Kbps 

20 Mbps 

100K 

Machine room network 

10 Mbps 
(shared) 

100 Mbps 
(switched) 

10 Gbps 
(switched) 

1000 

Ratio of users 
to computers 

100:1 

1:1 

1 :several 

100+ 
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Why should I study Operating 
Systems? 


29 



Why should I study Operating 
Systems? 

• Need to understand interaction between the hardware and 
software 

• Need to understand basic principles in the design of computer 
systems 

• efficient resource management, security, flexibility 
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Why should I study Operating 
Systems? 

• Because it enables you to do things that are difficult/impossible 
otherwise. 
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Example: Rio: I/O sharing implemented in 
the operating system kernel 
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Observation: I/O devices important for 

personal computers 
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A personal computer today 

• Super AMOLED display 

• Capacitive touchscreen (multitouch) 

• Audio (speaker, microphone) 

• Vibration 

• S pen 

• 13 MP front camera 

• 2 MP back camera 

• Accelerometer 

• Gyroscope 

• Proximity sensor 

• Compass 

• Barometer 

• Temperature sensor 

• Humidity sensor 

• Gesture sensor 

• GPS 

• 4G LTE 

• NFC 

• WiFi 

• Bluetooth 

• Infrared 

• 64 GB internal storage (extended by microSD) 

• Adreno 330 GPU 

• Hexagon DSP 

• Multimedia processor 
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A personal computer today 



Super AMOLED display 
Capacitive touchscreen (multitouch) 
Audio (speaker, microphone) 
Vibration 
S pen 

13 MP front camera 

Acceleromete^^^^^^^^^^^^ 

Gyroscope 

Proximity sensor 

Compass 

Barometer 

Temperature sensor 

Humidity sensor 

Gesture sensor 

GPS 

4G LTE 

NFC 


interaction 


WiFi 

Bluetooth 

Infrared 

64 GB internal storage (extended by microSD) 
Adreno 330 GPU 
Hexagon DSP 
Multimedia processor 
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A personal computer today 



• 

Super AMOLED display 

• 

Capacitive touchscreen (multitouch) 

• 

Audio (speaker, microphone) 

• 

Vibration 

• 

S pen 

• 

13 MP front camera 

• 

9 MP hank r.a mpra 

• 

Accelerometer 

• 

Gyroscope 

• 

Proximity sensor 

• 

Compass 

• 

Barometer 

• 

Temperature sensor 

• 

Humidity sensor 

• 

Gesture sensor 

• 

GPS 

• 

4G LTE 

• 

NFC 


sensing 


WiFi 

Bluetooth 

Infrared 

64 GB internal storage (extended by microSD) 
Adreno 330 GPU 
Hexagon DSP 
Multimedia processor 
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A personal computer today 



Super AMOLED display 
Capacitive touchscreen (multitouch) 
Audio (speaker, microphone) 
Vibration 
S pen 

13 MP front camera 
2 MP back camera 
Accelerometer 
Gyroscope 
Proximity sensor 
Compass 
Barometer 
Temperature sensor 
Humidity sensor 
Gesture sensor 
GPS 


connectivity, 

storage 
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64 GB internal storage (extended by microSD) 

Hexagon DSP 
Multimedia processor 
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A personal computer today 



Super AMOLED display 
Capacitive touchscreen (multitouch) 
Audio (speaker, microphone) 
Vibration 
S pen 

13 MP front camera 

2 MP back camera 

Accelerometer 

Gyroscope 

Proximity sensor 

Compass 

Barometer 

Temperature sensor 

Humidity sensor 

Gesture sensor 

GPS 

4G LTE 

NFC 


WiFi 

Bluetooth 

Infrared 

6^G^ntema^toma^extendecH3v 

AdrenosSTOPt^^ - ^^™^^ 

Hexagon DSP 1 

Multimedia processor I 


microSD) 

acceleration 
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Multiple computers for unique I/O 
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Multiple computers for unique I/O 




Multiple computers for unique I/O 





I/O sharing 



42 



How to build this? 
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Application layer 



• MightyText 

Server 



Client 





Do not meet our criteria 


High engineering effort 
No support for legacy applications 
No support for all I/O device features 



Rio: I/O servers for sharing I/O between 

mobile systems 



Ardalan Amiri Sani, Kevin Boos, Min Hong Yun, and Lin Zhong, "Rio: A System Solution for Sharing I/O between Mobile 46 
Systems," in Proc. ACM MobiSys, June 2014. (Best Paper Award) 


Key idea: device files as the boundary 


I/O devices abstracted as 
(device) files in Unix-like OSes 

e.g., /dev/foo 
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Key idea: device files as the boundary 
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Key idea: device files as the boundary 



Application 

~K~ 


File operations 


V 


User space 
Kernel 





Client 


User space 
Kernel 


Device file 

/dev/foo 


Device driver 



Server 
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Key idea: device files as the boundary 



File operations 


User space 


Kernel 


Virtual device file 

/dev/foo 




User space 
Kernel 


Device file 

/dev/foo 


Device driver 



Server 



Client 




Key idea: device files as the boundary 



Application 
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File operations 


User space 


Kernel 


Virtual device file N 

/dev/foo A 


Stub 


Wireless 

Link 





User space 
Kernel 
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^ Device file 
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Device driver 





I/O device 
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Video demo of Rio 


http://www.ruf.rice.edu/~mobile/rio.html 
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Operating systems are everywhere 
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Operating systems are everywhere 
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Operating systems are everywhere 
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Operating systems are everywhere 
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Overview 


•What is an operating system? 

•Operating systems history 

•Computer system and operating system structure 
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Operating systems history 


•Early Operating Systems 

•Simple Batch Systems 

•Multiprogrammed Batch Systems 

•Time-sharing Systems 

•Personal and mobile Computer Systems 
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log (people per computer) 


People-to-Computer Ratio Over 
Time 



streaming 
information 
to/from physical 
► world 


David Culler (Berkeley) 


year 
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Early Systems - Bare Machine 
(1950s) 


Hardware - expensive ; Human - cheap 


•Structure 

• Large machines run from console 

• Single user system 

• Programmer/User as operator 

• Paper tape or punched cards 



•Early software 

•Assemblers, compilers, linkers, loaders, 
device drivers, libraries of common subroutines. 


•Secure execution 

•Inefficient use of expensive resources 

• Low CPU utilization, high setup time. 
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Batch Systems (1960’s) 


• Reduce setup time by batching jobs with similar requirements. 


• Hire an operator 

• User is NOT the operator 
•Automatic job sequencing 

• Forms a rudimentary OS. 

• Resident Monitor 

• Holds initial control, control transfers to job 
and then back to monitor. 

• Problem 



• Need to distinguish job from job and data from program. 

• Special cards indicate what to do. 

• User program prevented from performing I/O 
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Batch Systems (1960’s) 


Solutions to speed up I/O: 

Offline Processing 

• load jobs into memory from tapes, card reading and line printing are done 
offline. 

• User submits card deck 

• cards put on tape 

• tape processed by operator 

• output written to tape 

• tape printed on printer 

• Separate user from computer 

Problems 

• Long turnaround time - up to 2 DAYS!!! 

• Low CPU utilization 

• I/O and CPU could not overlap; slow mechanical devices. 



Batch Systems (1960’s) 

• Solutions to speed up I/O: 

• Spooling (Simultaneous Peripheral Operation On-Line) 

• Use disk (random access device) as large storage for reading as many input 
files as possible and storing output files until output devices are ready to 
accept them. 

• Allows overlap - I/O of one job with computation of another. 

• Introduces notion of a job pool that allows OS choose next job to run so as 
to increase CPU utilization. 
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Speeding up I/O: Direct Memory 
Access (DMA) 

• Data moved directly between I/O devices and memory 

• CPU can work on other tasks 
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Batch Systems - I/O completion 


•How do we know that I/O is complete? 

• Polling: 

• Device sets a flag when it is busy. 

• Program tests the flag in a loop waiting for completion of I/O. 

• Interrupts: 

• On completion of I/O, device forces CPU to jump to a specific 
instruction address that contains the interrupt service routine. 

• After the interrupt has been processed, CPU returns to code it was 
executing prior to servicing the interrupt. 
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Multiprogramming 


•Use interrupts to run multiple programs simultaneously 

• When a program performs I/O, instead of polling, execute another 
program till interrupt is received. 

•Requires secure memory, I/O for each program. 
•Requires intervention if program indefinite loops. 
•Requires CPU scheduling to choose the next job to run. 
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Timesharing 


Hardware - getting cheaper, Human - getting expensive 

•Programs queued for execution in FIFO order. 

•Like multiprogramming, but timer device interrupts after 
a quantum (timeslice). 

• Interrupted program is returned to end of FIFO 

• Next program is taken from head of FIFO 

•Control card interpreter replaced by command 
language interpreter. 
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Timesharing (cont.) 


•Interactive (action/response) 

•when OS finishes execution of one command, it seeks the next 
control statement from user. 

•File systems 

• online filesystem is required for users to access data and code. 

•Virtual memory 

• Job is swapped in and out of memory to disk. 
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Personal Computing Systems - 
desktops 


Hardware - cheap ; Human - expensive 


•Single user systems, portable. 

•I/O devices - keyboards, mice, display screens, small 
printers. 

•Single user systems may not need advanced CPU 
utilization or protection features. 

•Advantages: 

• user convenience, responsiveness, ubiquitous 
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Personal Computing Systems - 
Mobile and wearable Systems 


Hardware - very cheap ; Human - very expensive 

•Single user, multiple computers 

•Laptops 

•Smartphones 

•Tablets 

•Smart glasses 

•Smart watches 
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Overview 


•What is an operating system? 

•Operating systems history 

•Computer system and operating system structure 
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Computer System & OS Structures 


•Computer System Organization 

•Process abstraction and hardware protection 

•System call and OS services 

•Storage architecture 

•OS organization 

•OS tasks 

•Virtual Machines 
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Computer System Organization 


CPU 


disks 

6 = 3(3 


mouse keyboard printer monitor 
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CPU execution 




xecution sequence: 

• Fetch Instruction at PC 

• Decode 

• Execute (possibly using registers) 

• Write results to registers/mem 

• PC = Next Instruction(PC) 

• Repeat 


From Berkeley OS course 


Addr 2 32 -1 



Datal 

DataO 

Inst237 

Inst236 

Inst5 

Inst4 

Inst3 

Inst2 

Instl 

InstO 


AddrO 


PC 

PC 

PC 

PC 
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Computer System Organization 


I/O devices 
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I/O devices 


•I/O devices and the CPU execute concurrently. 

•Each device controller is in charge of a particular 
device type 

•Each device controller has a local buffer. I/O is from the 
device to local buffer of controller 

•CPU moves data from/to main memory to/from the 
local buffers 

•Device controller interrupts CPU on completion of 
I/O 
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Interrupts 


•Interrupt transfers control to the interrupt service routine 

• Interrupt Service Routine: Segments of code that determine action 
to be taken for interrupt. 

•Determining the type of interrupt 

• Polling: same interrupt handler called for all interrupts, which then 
polls all devices to figure out the reason for the interrupt 

• Interrupt Vector Table: different interrupt handlers will be executed 
for different interrupts 




16 

0083h 

17 

008Bh 

18 
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19 

009Bh 

20 

00A3h 

21 
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22 
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5 

002Bh 

6 

0033h 

7 
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Interrupt handling 


•OS preserves the state of the CPU 

•stores registers and the program counter (address of interrupted 
instruction). 

•Incoming interrupts are disabled while another 
interrupt is being processed to prevent a lost 
interrupt. 
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Different types of I/O processing for 
programs 


•Synchronous I/O 

•After I/O is requested, wait until I/O is done. Program will be 
idle. 


•Asynchronous I/O 

•After I/O is requested, control returns to user program 
without waiting for I/O completion. 
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Direct Memory Access (DMA) 


• Used for high speed I/O 
devices able to transmit 
information at close to memory 
speeds. 

• Device controller transfers 
blocks of data from buffer 
storage directly to main 
memory without CPU 
intervention. 
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Process Abstraction 
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Process Abstraction 

• Process: an instance of a program, running 
with limited rights 
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Process Abstraction 

• Process: an instance of a program, running 
with limited rights 

— Thread: a sequence of instructions within a 
process 

• Potentially many threads per process (for now 1:1) 

- Address space: set of rights of a process 

• Memory that the process can access 

• Other permissions the process has (e.g., which system 
calls it can make, what files it can access) 
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How to limit process rights? 
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Hardware Protection 


•Dual Mode Operation 
•Memory Protection 
•CPU Protection 
•I/O Protection 


85 



Should a process be able to execute 
any instructions? 
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Should a process be able to execute 
any instructions? 

• No 

• Can alter system configuration 

• Can access unauthorized memory 

• Can access unauthorized I/O 

• etc. 

• How to prevent? 
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Dual-mode operation 


• Provide hardware support to differentiate between at 
least two modes of operation: 

1 . User mode -- execution done on behalf of a user. 

2. Kernel mode (monitor/supervisor/system mode) -- 
execution done on behalf of operating system. 

• “Privileged” instructions are only executable in the 
kernel mode 

• Executing privileged instructions in the user mode 
“traps” into the kernel mode 

•Trap is a software generated interrupt caused either by an error or 
a user request 
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Dual-mode operation(cont.) 

• Mode bit added to computer 
hardware to indicate the current 
mode: kernel(O) or user(1 ). 

Interrupt/ 

• When an interrupt or trap fault 

occurs, hardware switches to 

kernel mode. 




Kernel 



Set 

user 

mode 
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How to isolate memory access? 
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Process address space 


•Address space => the set of accessible 
addresses + state associated with them: 

• For a 32-bit processor there are 2 32 = 4 billion 
addresses 
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Virtual Address 

Virtual Addresses 
(Process Layout) 
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Address translation and memory 
protection 
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Memory Protection 

• Must provide memory protection at least for the interrupt 
vector and the interrupt service routines. 

•When a process is running, only memory in that process 
address space must be accessible. 

•When executing in kernel mode, the kernel has 
unrestricted access to all memory. 
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Memory Protection: base and bounds 


• To provide memory protection, add 
two registers that determine the 
range of legal addresses a program 
may address. 

• Base Register - holds smallest 
legal physical memory address. 

• Limit register - contains the size of 
the range. 

• Memory outside the defined range 
is protected. 


o 


300040 


420940 


1024000 



Base register 



300040 





120900 

Limit register 
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Virtually Addressed Base and Bounds 


Processor’s View 


Implementation Physical 

Memory 


Processor 


Virtual 

Virtual Memory 
Address 


Processor 


Virtual 

Address 


Base 


❖ 



Physical 

Address 


•> 


Bound 


Raise 

Exception 



Base 
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Bound 


The load instructions for the base and limit 
registers are privileged instructions. 
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CPU Protection 


•How to prevent a process from executing 
indefinitely? 


98 



CPU Protection 


•Timer - interrupts computer after specified period to 
ensure that OS maintains control. 

•Timer is decremented every clock tick. 

•When timer reaches a value of 0, an interrupt occurs. 

•Timer is commonly used to implement time sharing. 
•Timer is also used to compute the current time. 
•Load timer is a privileged instruction. 
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I/O Protection 


•All I/O instructions are privileged instructions. 


•Must ensure that a user program could never gain 
control of the computer in kernel mode, e.g., a user 
program must not be able to store a new address in 
the interrupt vector. 
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Question 


•Given the I/O instructions are privileged, how do 
users perform I/O? 
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Question 


•Given the I/O instructions are privileged, how do 
users perform I/O? 

•Via system calls - the method used by a process to 
request action by the operating system. 
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System Calls 

• User code can issue a syscall, which causes a trap 

• Kernel handles the syscall 



user process 

user mode 
(mode bit = 1) 

user process executing — ► calls system call return from system call 

\ / 


\ / 



' *- 

trap return 

kerne mode bit = 0 mode bit = 1 

* / 

kernel mode 
(mode bit = 0) 

execute system call 
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System Calls 

Interface between running 
program and the OS. 

•Assembly language instructions 
(macros and subroutines) 

• Some higher level languages 
allow system calls to be made 
directly (e.g. C) 

Passing parameters between a 
running program and OS via 
registers, memory tables or 
stack. 

Linux has about 300 system 
calls 

• read(), write(), openQ, close(), 

fork(), exec(), ioctlQ, 
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System services or system programs 


•Convenient environment for program development 
and execution. User view of OS is defined by 
system services, not system calls. 

• Command Interpreter (sh, csh, ksh) - parses/executes 
other system programs 

• File manipulation - copy (cp), print (Ipr), compare(cmp, 
diff) 

• File modification - editing (ed, vi, emacs) 

• Application programs - send mail (mail), read news (rn) 

• Programming language support (cc) 

• Status information, communication 

• etc.... 
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Command Interpreter System 


•Commands that are given to the operating system 
via command statements that execute 

•Process creation and deletion, I/O handling, Secondary 
Storage Management, Main Memory Management, File 
System Access, Protection, Networking. 

•Obtains the next command and executes it. 

•Programs that read and interpret control 
statements also called - 

•Control card interpreter, command-line interpreter, shell 
(in UNIX) 
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Storage Structure 


•Main memory - only large storage media that the 
CPU can access directly. 

•Secondary storage - extension of main memory 
that has large nonvolatile storage capacity. 
•Magnetic disks - rigid metal or glass platters covered with 
magnetic recording material. 

• Disk surface is logically divided into tracks, subdivided into 
sectors. 

• Disk controller determines logical interaction between device 
and computer. 
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Storage Hierarchy 


•Storage systems are organized in a hierarchy 
based on 
•Speed 
•Cost 
•Volatility 


•Caching - process of copying information into faster 
storage system; main memory can be viewed as 
fast cache for secondary storage. 


108 



Storage Device Hierarchy 
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Operating Systems: How are they 
organized? 


•Simple 

• Only one or two levels of code 

•Layered 

• Lower levels independent of upper levels 

•Modular 

•Core kernel with Dynamically loadable modules 

•Microkernel 

•OS built from many user-level processes 
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OS Structure - Simple Approach 


•MS-DOS - provides a lot of functionality in little 
space. 

•Not divided into modules, Interfaces and levels of 
functionality are not well separated 



Original UNIX System Structure 

•Limited structuring, has 2 separable parts 
•Systems programs 
• Kernel 

• everything below system call interface and above physical hardware. 

• Filesystem, CPU scheduling, memory management 



(the users) 
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Layered OS Structure 


OS divided into number of 
layers - bottom layer is 
hardware, highest layer is 
the user interface. 

Each layer uses functions 
and services of only 
lower-level layers. 


User Programs 
Interface Primitives 
Device Drivers and Schednlers 
Virtnal Memory 

i/o 

CPU Schednling 
Hardware 


•THE Operating System and 
Linux Kernel has successive 
layers of abstraction. 
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Layered Operating System 




Modules-based Structure 

•Most modern operating systems implement modules 

• Each core component is separate 

• Each talks to the others over known interfaces 

• Each is loadable as needed within the kernel 

•Overall, similar to layers but with more flexibility 

• Linux makes extensive use of modules 
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Monolithic vs. Microkernel OS 

•Monolithic OSes have large kernels with a lot of components 

•Linux, Windows, Mac 

•Microkernels moves as much from the kernel into “ user 
space 

•Small core OS running at kernel level 

•OS Services built from many independent user-level processes 

•Communication between modules with message passing 
•Benefits: 

• Easier to extend a microkernel 

• Easier to port OS to new architectures 

•More reliable (less code is running in kernel mode) 

• Fault Isolation (parts of kernel protected from other parts) 

• More secure 

•Detriments: 

• Performance overhead severe for naive implementation 1 16 



A microkernel OS 
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OS Task: Process Management 


•Process - fundamental concept in OS 

•Process is an instance of a program in execution. 

•Process needs resources - CPU time, memory, files/data 
and I/O devices. 

•OS is responsible for the following process 
management activities. 

• Process creation and deletion 
•Process suspension and resumption 
•Process synchronization and interprocess communication 
•Process interactions - deadlock detection, avoidance and 
correction 
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OS Task: Memory Management 


•Main Memory is an array of addressable words or 
bytes that is quickly accessible. 

•Main Memory is volatile. 

•OS is responsible for: 

• Allocate and deallocate memory to processes. 

• Managing multiple processes within memory - keep track of which 
parts of memory are used by which processes. Manage the 
sharing of memory between processes. 

• Determining which processes to load when memory becomes 
available. 
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OS Task: Secondary Storage and I/O 
Management 


•Since primary storage is expensive and volatile, 
secondary storage is required for backup. 

•Disk is the primary form of secondary storage. 

•OS performs storage allocation, free-space management 
and disk scheduling. 

•I/O system in the OS consists of 
•Buffer caching and management 
•Device driver interface that abstracts device details 
• Drivers for specific hardware devices 
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OS Task: File System Management 


•File is a collection of related information defined by 
creator - represents programs and data. 

•OS is responsible for 
•File creation and deletion 
• Directory creation and deletion 
•Supporting primitives for file/directory manipulation. 
•Mapping files to disks (secondary storage). 

•Backup files on archival media (tapes). 
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OS Task: Protection and Security 


•Protection mechanisms control access of programs and 
processes to user and system resources. 

• Protect user from himself, user from other users, system from 
users. 

•Protection mechanisms must: 

•Distinguish between authorized and unauthorized use. 
•Specify access controls to be imposed on use. 

•Provide mechanisms for enforcement of access control. 
•Security mechanisms provide trust in system and privacy 
•authentication, certification, encryption etc. 
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OS Task: Networking 


•Connecting processors in a distributed system 

•Distributed System is a collection of processors 
that do not share memory or a clock. 

•Processors are connected via a communication 
network. 

•Advantages: 

•Allows users and system to exchange information 

•provide computational speedup 

•increased reliability and availability of information 
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Virtual Machines 


Physical Machine 


Application 


OS 


Hardware 
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Virtual Machines 


Virtual Machine 1 Virtual Machine 2 Virtual Machine 3 


Application 


Application 


Application 

OS 


OS 


OS 


Virtual Machine Monitor (VMM) (aka Hypervisor) 


Hardware 


125 



Virtual Machines 


•Use cases 

• Resource configuration 

• Running multiple OSes, either the same or different 
OSes 

• Run existing OS binaries on different architecture 
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Summary of this week’s lecture 


•What is an operating system? 

•Operating systems history 

•Computer system and operating system structure 


127 



Principles of 
Operating Systems 

Lecture 14-15 - Virtual Memory 
Ardalan Amiri Sani ( ardalan@uci .edu ) 


[lecture slides contains some content adapted from previous slides by Prof. Nalini Venkatasubramanian, and 

course text slides © Silberschatz] 


Virtual Memory 


■ Background 

■ Demand paging 

□ Performance of demand paging 

■ Page Replacement 

□ Page Replacement Algorithms 

■ Allocation of Frames 

■ Thrashing 

■ Demand Segmentation 



Need for Virtual Memory 


■ Virtual Memory 

■ Separation of user logical memory from physical 
memory. 

■ Only PART of the program needs to be in memory for 
execution. 

■ Logical address space can therefore be much larger 
than physical address space. 

■ Need to allow pages to be swapped in and out. 

■ Virtual Memory can be implemented via 

□ Paging 

□ Segmentation 
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Paging/Segmentation Policies 


■ Fetch Strategies 

■ When should a page or segment be brought into primary 
memory from secondary (disk) storage? 

□ Demand Fetch 

□ Anticipatory Fetch 

■ Placement Strategies 

■ When a page or segment is brought into memory, where 
is it to be put? 

□ Paging - trivial 

□ Segmentation - significant problem 

■ Replacement Strategies 

■ Which page/segment should be replaced if there is not 
enough room for a required page/segment? 
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Demand Paging 


■ Bring a page into memory only when it is 
needed. 

□ Less I/O needed 

□ Less Memory needed 

□ Faster response 

□ More users 

■ The first reference to a page will trap to OS 
with a page fault. 

■ OS looks at another table to decide 

□ Invalid reference - abort 

□ Just not in memory. 



Valid-Invalid Bit 


□ With each page table entry a valid-invalid bit is 
associated (1 => in-memory, 0 => not in memory). 

□ Initially, valid-invalid bit is set to 0 on all entries. 

■ During address translation, if valid-invalid bit in page 
table entry is 0 — page fault occurs. 

■ Example of a page-table snapshot 

Frame # Valid-invalid bit 

1 

1 

1 

1 

0 


0 

0 

0 


Page Table 




Handling a Page Fault 


□ Page is needed - reference to page 

□ Step 1 : Page fault occurs - trap to OS (process suspends). 

□ Step 2: Check if the virtual memory address is valid. Kill 
job if invalid reference. If valid reference, and page not in 
memory, continue. 

□ Step 3: Bring into memory - Find a free page frame, map 
address to disk block and fetch disk block into page frame. 
When disk read has completed, add virtual memory 
mapping to indicate that page is in memory. 

□ Step 4: Restart instruction interrupted by illegal address 
trap. The process will continue as if page had always been 
in memory. 
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What happens if there is no free 
frame? 

■ Page replacement - find some page in 
memory that is not really in use and swap it. 

■ Need page replacement algorithm 

■ Performance Issue - need an algorithm which will result 
in minimum number of page faults. 

□ Same page may be brought into memory many 
times. 



Performance of Demand Paging 


■ Page Fault Ratio - 0 < p < 1 .0 

□ If p = 0, no page faults 

□ If p = 1 , every reference is a page fault 

■ Effective Access Time 

EAT = (1-p) * memory access + 

p * (page fault overhead + 

swap page out (only when needed) + 
swap page in + 
restart overhead + 
memory access) 
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Demand Paging Example 


■ Memory is always full 

□ Need to get rid of a page on every fault 

■ Memory Access time = 1 microsecond 

■ 50% of the time the page that is being replaced has 
been modified and therefore needs to be swapped 
out. 

■ Page fault and restart overheads are negligible 

■ Swap Page Time =10 msec = 10,000 microsec 
EAT = (1-p) *1 + p (15000 + 1) = 1 + 15000p microsec 

■ EAT is directly proportional to the page fault rate. 
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Page Replacement 


■ Prevent over-allocation of memory by 
modifying page fault service routine to 
include page replacement. 

■ Use modify(dirty) bit to reduce overhead of 
page transfers - only modified pages are 
written to disk. 

■ Page replacement 

■ large virtual memory can be provided on a smaller 
physical memory. 
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Page Replacement Algorithms 


■ Want lowest page-fault rate. 

■ Evaluate algorithm by running it on a 
particular string of memory references 
(reference string) and computing the number 
of page faults on that string. 

■ Assume reference string in examples to 
follow is 

1,2, 3,4, 1,2, 5, 1,2, 3,4, 5. 
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Page Replacement Strategies 


■ The Principle of Optimality 

□ Replace the page that will not be used again the farthest time 
into the future. ' 

■ Random Page Replacement 

□ Choose a page randomly 

■ FIFO - First in First Out 

□ Replace the page that has been in memory the longest. 

■ LRU - Least Recently Used (and its approximations) 

□ Replace the page that has not been used for the longest time. 

■ LFU - Least Frequently Used 

□ Replace the page that is used least often. 

■ MFU - Most Frequently Used 

□ Replace the page that is used most often. 
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First-In-First-Out (FIFO) Algorithm 


Reference String: 1,2, 3, 4, 1,2, 5, 1,2, 3, 4, 5 

■ Assume x frames ( x pages can be in 
memory at a time per process) 

9 Page faults 

10 Page faults 

FIFO Replacement - Belady’s Anomaly — more frames does not mean less page faults 
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Optimal Algorithm 


■ Replace page that will not be used for longest 
period of time. 

□ How do you know this??? 

□ Generally used to measure how well an algorithm 
performs. 

□ Reference String: 1,2, 3, 4, 1,2, 5, 1,2, 3, 4, 5 


4 frames 


Frame 1 

1 

4 

Frame 2 

2 


Frame 3 

3 


Frame 4 4 

5 


6 Page faults 
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Least Recently Used (LRU) 
Algorithm 

□ Use recent past as an approximation of near 
future. 

□ Choose the page that has not been used for the 
longest period of time. 

□ May require hardware assistance to implement. 

□ Reference String: 1,2, 3, 4, 1,2, 5, 1,2, 3, 4, 5 


4 frames 


Frame 1 

1 


5 

Frame 2 

2 



Frame 3 

3 

5 

4 

Frame 4 

4 

3 \ 


8 Page faults 
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Implementation of LRU algorithm 


■ Counter Implementation 

□ Every page entry has a counter; every time page is referenced 
through this entry, copy the clock into the counter. 

□ When a page needs to be changes, look at the counters to 
determine which page to change (page with smallest time value). 

■ Stack Implementation 

■ Keeps a stack of page numbers in a doubly linked form 

■ Page referenced 

□ move it to the top 

□ requires 6 pointers to be changed 

■ No search required for replacement 
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LRU Approximation Algorithms 


□ Reference Bit 

□ With each page, associate a bit, initially = 0. 

□ When page is referenced, bit is set to 1 . 

□ Replace the one which is 0 (if one exists). Do not know 
order however. 

□ Additional Reference Bits Algorithm 

□ Record reference bits at regular intervals. 

□ Keep 8 bits (say) for each page in a table in memory. 

□ Periodically, shift reference bit into high-order bit, l.e. shift 
other bits to the right, dropping the lowest bit. 

□ During page replacement, interpret 8bits as unsigned 
integer. 

□ The page with the lowest number is the LRU page. 
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LRU Approximation Algorithms 


□ Second Chance 

■ Core is a FIFO replacement algorithm 

■ Implemented with circular queue (hence called the clock 
algorithm sometimes) 

■ Need a reference bit. 

■ When a page is selected, inspect the reference bit. 

■ If the reference bit = 0, replace the page. 

■ If page to be replaced (in clock order) has reference bit = 
1 , then 

□ set reference bit to 0 

□ leave page in memory 

□ replace next page (in clock order) subject to same rules. 


19 



LRU Approximation Algorithms 


□ Enhanced Second Chance 

■ Need a reference bit and a modify bit as an ordered pair. 

■ 4 situations are possible: 

□ (0,0) - neither recently used nor modified - best page to replace. 

□ (0,1) - not recently used, but modified - not quite as good, 
because the page will need to be written out before 
replacement. 

□ (1 ,0) - recently used but clean - probably will be used again 
soon. 

□ (1,1)- probably will be used again, will need to write out before 
replacement. 
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Counting Algorithms 


■ Keep a counter of the number of references 
that have been made to each page. 

□ LFU (least frequently used) algorithm 

■ replaces page with smallest count. 

■ Rationale : frequently used page should have a large 
reference count. 

□ Variation - shift bits right, exponentially decaying count. 

□ MFU (most frequently used) algorithm 

■ replaces page with highest count. 

■ Based on the argument that the page with the smallest 
count was probably just brought in and has yet to be 
used. 
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Page Buffering Algorithm 


■ Keep pool of free frames 

■ Solution 1 

□ When a page fault occurs, choose victim frame. 

□ Desired page is read into free frame from pool before victim is 
written out. 

□ Allows process to restart soon, victim is later written out and 
added to free frame pool. 

■ Solution 2 

□ Maintain a list of modified pages. When paging device is idle, 
write modified pages to disk and clear modify bit. 

■ Solution 3 

□ Keep frame contents in pool of free frames and remember 
which page was in frame.. If desired page is in free frame pool, 
no need to page in. 
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Protection Bits 


Page Protection 

32 31 30 29 28 27 26 25 


Reference 

Valid 

Resident 

Dirty 

Write 

Read 

Execute 


Frame Address 


Segmentation Protection 

32 31 30 29 28 27 26 25 


Reference 

Valid 

Resident 

Dirty 

Write 

Read 

Execute 


Length 

Physical Address 


Reference - Page has been accessed 

- Page exists 

Resident - Page is cached in primary memory 

- Page has been changed since page in 
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Allocation of Frames 


□ Single user case is simple 

□ User is allocated any free frame 

□ Problem: Demand paging + multiprogramming 

■ Each process needs minimum number of pages based on 
instruction set architecture. 

■ Example IBM 370: 6 pages to handle MVC (storage to 
storage move) instruction 

□ Instruction is 6 bytes, might span 2 pages. 

□ 2 pages to handle from. 

□ 2 pages to handle to. 

■ Will need 8 pages if MVC used as an operand of EXECUTE 

■ Two major allocation schemes: 

□ Fixed allocation 

□ Priority allocation 
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Fixed Allocation 


■ Equal Allocation 

□ E.g. If 100 frames and 5 processes, give each 20 pages. 

■ Proportional Allocation 

■ Allocate according to the size of process 

□ Sj = size of process Pj 

□ S = isy 

□ m = total number of frames 

□ aj = allocation for Pj = Sj/S * m 

□ If m = 64, SI = 10, S2= 127 then 

al = 10/137 * 64 = 5 
a2= 127/137 * 64 = 59 
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Priority Allocation 


■ May want to give high priority process more 
memory than low priority process. 

■ Use a proportional allocation scheme using 
priorities instead of size 

■ If process Pi generates a page fault 

■ select for replacement one of its frames 

■ select for replacement a frame form a process with lower 
priority number. 
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Global vs. Local Allocation 


■ Global Replacement 

■ Process selects a replacement frame from the set of all 
frames. 

■ One process can take a frame from another. 

■ Process may not be able to control its page fault rate. 

■ Local Replacement 

■ Each process selects from only its own set of allocated 
frames. 

■ Process slowed down even if other less used pages of 
memory are available. 

■ Global replacement has better throughput 

■ Hence more commonly used. 
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Thrashing 


■ If a process does not have enough pages, 
the page-fault rate is very high. This leads to: 

■ low CPU utilization. 

■ OS thinks that it needs to increase the degree of 
multiprogramming 

■ Another process is added to the system. 

■ System throughput plunges... 

□ Thrashing 

• A process is busy swapping pages in and out. 

■ In other words, a process is spending more time paging 
than executing. 
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Thrashing (cont.) 


□ Why does demand paging work? 

□ Locality Model - computations have locality! 

□ Locality - set of pages that are actively used together. 

□ Process migrates from one locality to another. 

□ Localities may overlap. 



Number of Frames 
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Thrashing 


□ Why does thrashing occur? 

■ Y. (size °f locality) > total memory size 


CPU 

Utilization 
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Working Set Model 


■ A = working-set window 

■ a fixed number of page references, e.g. 10,000 instructions 

□ WSSj (working set size of process Pj) - total number of 
pages referenced in the most recent A (varies in time) 

■ If A too small, will not encompass entire locality. 

■ If A too large, will encompass several localities. 

■ lfA = °°, will encompass entire program. 

□ D = X WSSj = total demand frames 

■ If D > m (number of available frames) =>thrashing 

□ Policy: If D > m, then suspend one of the processes. 
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Keeping Track of the Working Set 


■ Approximate with 

■ interval timer + a reference bit 

□ Example: A = 10,000 references 

□ Timer interrupts after every 5000 references. 

□ Whenever a timer interrupts, copy and set the values of all 
reference bits to 0. 

□ Keep in memory 2 bits for each page (indicated if page was used 
within last 10,000 to 15,000 references). 

□ If one of the bits in memory = 1 => page in working set. 

■ Not completely accurate - cannot tell where reference 
occurred. 

■ Improvement - 10 bits and interrupt every 1000 time units. 
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Page fault Frequency Scheme 


■ Control thrashing by establishing acceptable page-fault 
rate (an upper bound and a lower bound). 

□ If page fault rate too low, process loses frame. 

□ If page fault rate too high, process needs and gains a 
frame. 



number of frames 
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Demand Paging Issues 


□ Prepaging 

■ Tries to prevent high level of initial paging. 

□ E.g. If a process is suspended, keep list of pages in 
working set and bring entire working set back before 
restarting process. 

□ Tradeoff - page fault vs. prepaging - depends on how many 
pages brought back are reused. 

□ Page Size Selection 

■ fragmentation 

■ table size 

■ I/O overhead 

■ locality 
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Demand Paging Issues 


□ Program Structure 

■ Array A[1 024, 1 024J of integer 

■ Assume each row is stored on one page 

■ Assume only one frame in memory 

■ Program 1 

for j := 1 to 1024 do 
for i := 1 to 1024 do 
AD j] := 0; 

1024 * 1024 page faults 
m Program 2 

for i := 1 to 1024 do 
for j:= 1 to 1024 do 

AD j] := 0; 

1024 page faults 
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Demand Paging Issues 


■ I/O Interlock and addressing 

■ Say I/O is done to/from virtual memory. I/O is 
implemented by I/O controller. 

□ Process A issues I/O request 

□ CPU is given to other processes 

□ Page faults occur - process A’s pages are paged out. 

□ I/O now tries to occur - but frame is being used for another 
process. 

■ Solution 1 : never execute I/O to process memory - I/O 
takes place into system memory. Copying Overhead!! 

■ Solution 2: Lock pages in memory - cannot be selected 
for replacement. 
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Demand Segmentation 


■ Used when there is insufficient hardware to 
implement demand paging. 

■ OS allocates memory in segments, which it 
keeps track of through segment descriptors. 

■ Segment descriptor contains valid bit to indicate whether 
the segment is currently in memory. 

□ If segment is in main memory, access continues. 

□ If not in memory, segment fault is triggered. 
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Principles of 
Operating Systems 

Lecture 16-17 - File-System Interface and Implementation 
Ardalan Amiri Sani ( ardalan@uci.edu ) 


[lecture slides contains some content adapted from previous slides by Prof. Nalini Venkatasubramanian, and 

course text slides © Silberschatz] 


Outline 


■ File Concept and Structure 

■ Directory Structures 

■ File Organizations 

■ Access Methods 

■ Protection 



File Concept 


□ Contiguous logical address space 

■ OS abstracts from the physical properties of its storage 
device to define a logical storage unit called file. 

■ Persistent 

■ OS maps files to physical devices. 

□ Types 

■ Data 

□ numeric, character, binary 

■ Program 

□ source, object (load image) 

■ Documents 
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File Structure 


□ None - sequence of words/bytes 

□ Simple record structure 

□ Lines 

□ Fixed Length 

□ Variable Length 

□ Complex Structures 

□ Formatted document 

□ Relocatable Load File 

□ Can simulate last two with first method by 
inserting appropriate control characters 

□ Who decides 

□ Operating System 

□ Program 


4 



File Attributes 

□ Name 

□ symbolic file-name, only information in human-readable form 

□ Identifier 

□ Unique tag that identifies file within file-system; non-human readable name 

□ Type 

□ for systems that support multiple types 

□ Location 

□ pointer to a device and to file location on device 

□ Size 

□ current file size, maximal possible size 

□ Protection 

□ controls who can read, write, execute 

□ Time, Date and user identification 

□ data for protection, security and usage monitoring 

□ Information about files are kept in the directory structure, 
maintained on disk 



File types - name. extension 


File Type 

Possible extension 

Function 

Executable 

Exe,com,bin 

Machine language 
program 

Object 

o 

cr 

V i. 

*> 

o 

Compiled machine lang., 
not linked 

Source code 

c, CC, p, java, asm... 

Source code in various 
languages 

Batch 

Bat, sh 

Commands to command 
interpreter 

text 

Txt, doc 

Textual data, documents 

Print, view 

ps, dvi, gif 

ASCII or binary file 

archive 

Arc, zip, tar 

Group of files, sometimes 
compressed 

Library 

Lib, a 

Libraries of routines 



File Operations 


□ A file is an abstract data type. It can be defined by 
operations: 

■ Create a file 

■ Write a file 

■ Read a file 

■ Reposition within file - file seek 

■ Delete a file 

■ Truncate a file 

■ Open(Fi) 

□ search the directory structure on disk for entry Fi, and move the 
content of entry to memory. 

. Close(Fi) 

□ move the content of entry Fi in memory to directory structure on 
disk. 
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Directory Structure 


□ Number of files on a system can be extensive 

□ Break file systems into partitions (treated as a separate 
storage device) 

□ Hold information about files within partitions. 

□ Device Directory: A collection of nodes containing 
information about all files on a partition. 

□ Both the directory structure and files reside on 
disk. 

□ Backups of these two structures are kept on 
tapes. 



Information in a Device Directory 


□ File Name 

□ File Type 

□ Address or Location 

□ Current Length 

□ Maximum Length 

□ Date created, Date last accessed (for archival), 
Date last updated (for dump) 

□ Owner ID (who pays), Protection information 

■ Also on a per file, per process basis 

□ Current position - read/write position 

□ usage count 



Operations Performed on Directory 


□ Search for a file 

□ Create a file 

□ Delete a file 

□ List a directory 

□ Rename a file 

□ T raverse the file-system 
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Logical Directory Organization -- 
Goals 

■ Efficiency - locating a file quickly 

■ Naming - convenient to users 

■ Two users can have the same name for different files. 

■ The same file can have several different names. 

■ Grouping 

■ Logical grouping of files by properties (e.g. all Python 
programs, all games, all pictures...) 
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Single Level Directory 


■ A single directory for all users 

■ Nanning Problem and Grouping Problem 

□ As the number of files increases, difficult to remember 
unique names 

□ As the number of users increase, users must have unique 

names. Directory 



Files 
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Two Level Directory 


■ Introduced to remove naming problem 
between users 

□ First Level contains list of user directories 

□ Second Level contains user files 

□ Need to specify Path name 

□ Can have same file names for different users. 

□ System files kept in separate directory or Level 1 . 

□ Efficient searching 
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Two Level Directory 
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Tree structured Directories 
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Tree Structured Directories 


■ Arbitrary depth of directories 

■ Leaf nodes are files, interior nodes are directories. 

■ Efficient Searching 

■ Grouping Capability 

■ Current Directory (working directory) 

■ cd spell/mail/prog, cd .. 

■ dir, Is 

■ MS-DOS uses a tree structured directory 
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Tree Structured Directories 


□ Absolute or relative path name 

□ Absolute from root 

□ Relative paths from current working directory pointer. 

□ Creating a new file is done in current directory 

□ Creating a new subdirectory is done in current 
directory, e.g. mkdir <dir-name> 

□ Delete a file , e.g. rm file-name 

□ Deletion of directory 

■ Option 1 : Only delete if directory is empty 

■ Option 2: delete all files and subdirectories under 
directory 
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Acyclic Graph Directories 



Files 
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Acyclic Graph Directories 

■ Acyclic graphs allow sharing 

■ Implementation by links 

■ Links are pointers to other files or subdirectories 

■ Symbolic links or relative path name 

□ Directory entry is marked as a link and name of real 
file/directory is given. Need to resolve link to locate file. 

■ Implementation by shared files 

■ Duplicate information in sharing directories 

■ Original and copy indistinguishable. 

■ Need to maintain consistency if one of them is modified. 
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Acyclic Graph Directories 


□ Naming : File may have multiple absolute path names 

■ Two different names for the same file 

□ Traversal 

□ ensure that shared data structures are traversed only once. 

□ Deletion 

■ Removing file when someone deletes it may leave dangling 
pointers. 

■ Preserve file until all references to it are deleted 

□ Keep a list of all references to a file or 

□ Keep a count of the number of references - reference count. 

□ When count = 0, file can be deleted. 
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General Graph Directories 
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General Graph Directories (cont.) 


□ How do we guarantee no cycles in a tree 
structured directory? 

□ Allow only links to file not subdirectories. 

□ Every time a new link is added use a cycle detection 
algorithm to determine whether it is ok. 

□ If links to directories are allowed, we have a 
simple graph structure 

□ Need to ensure that components are not traversed twice 
both for correctness and for performance, e.g. search 
can be non-terminating. 

□ File Deletion - reference count can be non-zero 

□ Need garbage collection mechanism to determine if file 
can be deleted. 
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Access Methods 


■ Sequential Access 

read next 
write next 
reset 

■ Direct Access ( n = relative block number) 

read n 
write n 
position to n 
read next 
write next 
rewrite n 
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Sequential File Organization 


start 


current position 


record 
or byte 0 


Record 
or byte n 



End 
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Indexed Sequential or Indexed 
File Organization 


start 


Record Record 

with Key -> Location with Overflow Area 

Key 0 Key n 
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Direct Access File Organization 


start 


Disk Block 0 


Disk Block n 



Key 


End 
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Protection 


■ File owner/creator should be able to control 

■ what can be done 

■ by whom 

■ Types of access 

□ read 

□ write 

□ execute 

□ append 

□ delete 

□ list 
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Access lists and groups 


□ Associate each file/directory with access list 

■ Problem - length of access list.. 

□ Solution - condensed version of list 

■ Mode of access: read, write, execute 

■ Three classes of users 

□ owner access - user who created the file 

□ groups access - set of users who are sharing the file and need 
similar access 

□ public access - all other users 

■ In UNIX, 3 fields of length 3 bits are used. 

□ Fields are user, group, others(u,g,o), 

□ Bits are read, write, execute (r,w,x). 

□ E.g., chmod +rw file , chmod 761 game 
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File-System Implementation 


■ File System Structure 

■ Allocation Methods 

■ Free-Space Management 

■ Directory Implementation 

■ Efficiency and Performance 

■ Recovery 
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File-System Structure 


■ File Structure 

■ Logical Storage Unit with collection of related information 

□ File System resides on secondary storage (disks). 

■ To improve I/O efficiency, I/O transfers between memory 
and disk are performed in blocks. 

□ Read/Write/Modify/Access each block on disk. 

■ File system organized into layers. 

■ File control block - storage structure 
consisting of information about a file. 
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File System Mounting 


■ File System must be mounted before it can 
be available to processes on the system 

■ The OS is given the name of the device and the mount 
point (location within file structure at which files attach). 

■ OS verifies that the device contains a valid file system. 

■ OS notes in its directory structure that a file system is 
mounted at the specified mount point. 
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Allocation of Disk Space 


■ Low level access methods depend upon the 
disk allocation scheme used to store file data 

□ Contiguous Allocation 

□ Linked List Allocation 

□ Indexed Allocation 
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Contiguous Allocation 


□ Each file occupies a set of contiguous blocks on the disk. 

□ Simple - only starting location (block #) and length (number of 
blocks) are required. 

□ Suits sequential or direct access. 

□ Fast (very little head movement) and easy to recover in the 
event of system crash. 

■ Problems 

□ Wasteful of space (dynamic storage-allocation problem). Use 
first fit or best fit. Leads to external fragmentation on disk. 

□ Files cannot grow - expanding file requires copying 

□ Users tend to overestimate space - internal fragmentation. 

□ Mapping from logical to physical - <Q,R> 

□ Block to be accessed = Q + starting address 

□ Displacement into block = R 
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Contiguous Allocation 


Directory 


File 


Start 7 length \ 
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Linked Allocation 


■ Each file is a linked list of disk blocks 


■ Blocks may be scattered anywhere on the disk. 

■ Each node in list can be a fixed size physical block or a 
contiguous collection of blocks. 

■ Allocate as needed and then link together via pointers. 

□ Disk space used to store pointers, if disk block is 512 bytes, 
and pointer (disk address) requires 4 bytes, user sees 508 
bytes of data. 

■ Pointers in list not accessible to user. 


Block = 


pointer 


Data 
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Linked Allocation 


Directory 
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Linked Allocation 


□ Simple - need only starting address. 

□ Free-space management system - space efficient. 

■ Can grow in middle and at ends. No estimation of size 
necessary. 

□ Suited for sequential access but not random 
access. 

□ Directory Table maps files into head of list for a 
file. 

□ Mapping - <Q, R> 

□ Block to be accessed is the Qth block in the linked chain of 
blocks representing the file. 

□ Displacement into block = R + 1 
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Linked Allocation (cont.) 


□ Slow 

□ Need to read through linked list nodes sequentially to find 
the record of interest. 

□ Not very reliable 

□ System crashes can scramble files being updated. 

□ Important variation on linked allocation method 

■ File-allocation table (FAT) - disk-space allocation used 
by MS-DOS and OS/2. 
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File Allocation Table (FAT) 


m Instead of link on each 
block, put all links in 
one table 

□ the File /Allocation Table 
— i.e., FAT 

• One entry per physical 
block in disk 

□ Directory points to first 
block of file 

□ Each block points to 
next block (or End Of 
File (EOF)) 


directory entry 


test 


217 


name 


start block 


0 


■>217 


339 


618 


no. of disk blocks -1 


618 


339 


FAT 


CS-4513, D-Term 2007 


File Implementations 
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FAT File Systems 


■ Advantages 

□ Advantages of Linked File System 

□ FAT can be cached in memory 

□ Searchable at CPU speeds, pseudo-random access 

■ Disadvantages 

□ Not suitable for very large disks 

■ FAT cache describes entire disk, not just open files! 

□ Not fast enough for large databases 

■ Used in MS-DOS, early Windows systems 


File Implementations 


CS-4513, D-Term 2007 
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Disk Defragmentation 


■ Re-organize blocks in disk so that file is 
(mostly) contiguous 

■ Link or FAT organization preserved 

■ Purpose: 

□ To reduce disk arm movement during sequential 
accesses 


File Implementations 


CS-4513, D-Term 2007 
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Indexed Allocation 


Brings all pointers together into the index 
block. 


Logical view 


Index table 



42 









Indexed Allocation 


Directory 
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Indexed Allocation (cont.) 


■ Need index table. 

■ Supports sequential and direct access. 

■ Dynamic access without external fragmentation, but 
have overhead of index block. 

□ Mapping from logical to physical in a file of maximum size 
of 256K words and block size of 512 words. We need only 
1 block for index table. 

■ Mapping - <Q,R> 

□ Q - displacement into index table 

□ R - displacement into block 
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Indexed Allocation - Mapping 


□ Mapping from logical to physical in a file of 

unbounded length. 

□ Linked scheme - 

■ Link blocks of index tables (no limit on size) 

□ Multilevel Index 

■ E.g. Two Level Index - first level index block points to a 
set of second level index blocks, which in turn point to 
file blocks. 

■ Increase number of levels based on maximum file size 
desired. 

■ Maximum size of file is bounded. 
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Indexed File - 



link 


Linked Scheme 


file block 



link 








Indexed Allocation - Multilevel 









Combined Scheme 



UNIX Inode 
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What is an inode? 


■ An inode (index node) is a control structure that contains 
key information needed by the OS to access a particular 
file. Several file names may be associated with a single 
inode, but each file is controlled by exactly ONE inode. 

■ On the disk, there is an inode table that contains the 
inodes of all the files in the filesystem. When a file is 
opened, its inode is brought into main memory and stored 
in a memory-resident inode table. 


Copyright ©: Nahrstedt, Angrave, Abdelzaher 
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Directories 

■ In Unix a directory is simply a file that contains a list of file 
names plus pointers to associated inodes 


Inode table 



Directory 


il 

Namel 

i2 

Name2 

i3 

Name3 

i4 

Name4 


Copyright ©: Nahrstedt, Angrave, Abdelzaher 





Free Space Management 


■ Bit Vector ( n blocks) - bit map of free blocks 


0 12 


/!- 1 


bit[i] = 


{ 1 implies block[i] free 
0 implies block[i] occupied 


■ Block number calculation 
(number of bits per word) * 

(number of 0-value words) + 
offset of 1 st bit 

■ Bit map requires extra space. 

□ E.g., Block size = 2 A 1 2 bytes, Disk size = 2 A 30 bytes 
n = 2 A 30/2 A 12 = 2 A 18 bits (or 32 kbytes) 

■ Easy to get contiguous files 

■ Example: BSD File system 
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Free Space Management 

□ Linked list (free list) 

□ Keep a linked list of free blocks 

□ Cannot get contiguous space easily, not very efficient because 
linked list needs traversal. 

□ No waste of space 

□ Linked list of indices - Grouping 

□ Keep a linked list of index blocks. Each index block contains 
addresses of free blocks and a pointer to the next index block. 

□ Can find a large number of free blocks quickly. 

□ Counting 

□ Linked list of contiguous blocks that are free 

□ Free list node contains pointer and number of free blocks 
starting from that address. 
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Free Space Management 

■ Need to protect 

■ pointer to free list 

■ Bit map 

□ Must be kept on disk 

□ Copy in memory and disk may differ. 

□ Cannot allow for block[i] to have a situation where bit[i] 
in memory and bit[i] = 0 on disk 

■ Solution 

■ Set bit[i] = 1 in disk 

■ Allocate block[i] 

■ Set bit[i] = 1 in memory. 



Directory Implementation 


■ Linear list of file names with pointers to the data 
blocks 

■ simple to program 

■ time-consuming to execute - linear search to find entry. 

■ Sorted list helps - allows binary search and decreases search 
time. 

■ Hash Table - linear list with hash data structure 

■ decreases directory search time 

■ collisions - situations where two file names hash to the same 
location. 

■ Each hash entry can be a linked list - resolve collisions by 
adding new entry to linked list. 
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Efficiency and Performance 


□ Efficiency dependent on: 

□ Disk allocation and directory algorithms 

□ Types of data kept in the files directory entry 

□ Performance improved by: 

■ On-board cache - for disk controllers 

■ Disk Cache - separate section of main memory for frequently 
used blocks. Block replacement mechanisms 

□ LRU 

□ Free-behind - removes block from buffer as soon as next block 
is requested. 

□ Read-ahead - request block and several subsequent blocks are 
read and cached. 

■ Improve PC performance by dedicating section of memory as 
virtual disk or RAM disk. 
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Recovery 


■ Ensure that system failure does not result in 
loss of data or data inconsistency. 

■ Consistency checker 

■ E.g., compares data in directory structure with data 
blocks on disk and tries to fix inconsistencies. 

■ Backup and Restore 

■ Use system programs to back up data from disk to 
another storage device (e.g., magnetic tape). 

■ Recover lost file or disk by restoring data from backup. 
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Principles of 
Operating Systems 


Lecture 3-5 - Processes and Threads 
Ardalan Amiri Sani ( ardalan@uci.edu ) 


[lecture slides contains some content adapted from : previous slides by Prof. Nalini Venkatasubramanian, 
http://www-inst.eecs.berkeley.edu/~cs162/ Copyright ©2010 UCB, and course text slides © Silberschatz] 
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Outline 


■ Process Concept 

■ Process Scheduling 

■ Operations on Processes 

■ Cooperating Processes 

■ Threads 

■ Interprocess Communication 



Process Concept 


■ An operating system executes a variety of 
programs 

■ batch systems - jobs 

■ time-shared systems - user programs or tasks 

■ job and program used interchangeably 

■ Process - a program in execution (with limited 
rights) 

■ process execution proceeds in a sequential fashion 

■ A process contains 

■ program counter, stack and data section 
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Process =? Program 




■ More to a process than just a program: 

□ Program is just part of the process state 

□ I run Vim on lectures.txt, you run it on homework.java - Same program, 
different processes 

■ Less to a process than a program: 

□ A program can invoke more than one process 

□ cc/cpp starts up processes to handle different stages of the compilation 
process ccl, cc2, as, and Id 
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Process State 


■ A process changes state as it executes. 



Process States 


■ New - The process is being created. 

■ Running - Instructions are being executed. 

■ Waiting - Waiting for some event to occur. 

■ Ready - Waiting to be assigned to a 
processor. 

■ Terminated - Process has finished execution. 



Process Control Block 


■ Contains information 

associated with each process 

■ Process State - e.g. new, 
ready, running etc. 

■ Process Number - Process ID 

■ Program Counter - address of 
next instruction to be executed 

■ CPU registers - general 
purpose registers, stack pointer 
etc. 

■ CPU scheduling information - 
process priority 

■ Memory Management 
information - base/limit 
information 

■ Accounting information - time 
limits, I/O resources 


process state 
process number 
program counter 


registers 


memory limits 
list of open files 


Process 

Control 

Block 
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Process Scheduling 

Process (PCB) moves from queue to queue 
When does it move? Where? A scheduling decision 





Process Scheduling Queues 


■ Job Queue - set of all processes in the system 

■ Ready Queue - set of all processes residing in main 
memory, ready and waiting to execute. 

■ Device Queues - set of processes waiting for an I/O 
device. 

■ Process migration between the various queues. 

■ Queue Structures - typically linked list, circular list 
etc. 



Process Queues 




Ready 

Queue 


Ready 

Queue 


pointer 


p recess state 


process number 


prcgram counter 


a rea fo r register saves 






pointer 


process state 


process number 


pro-gram counter 


area for register saves 
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p rocess state 
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Enabling Concurrency and 
Protection: Multiplex processes 


Only one process (PCB) active at a time 

□ Current state of process held in PCB: 

■ “snapshot” of the execution and protection environment 

□ Process needs CPU, resources 

Give out CPU time to different processes 
(Scheduling): 

□ Only one process “running” at a time 

□ Give more time to important processes 

Give pieces of resources to different processes 
(Protection): 

□ Controlled access to non-CPU resources 

■ E.g. Memory Mapping: Give each process their own 
address space 


process state 
process number 
program counter 


registers 


memory limits 
list of open files 


• • • 


Process 
Control 
Block ii 



Enabling Concurrency: Context 
Switch 

■ Task that switches CPU from one process to 
another process 

□ the CPU must save the PCB state of the old process and 
load the saved PCB state of the new process. 

■ Context-switch time is overhead 

□ System does no useful work while switching 

□ Overhead sets minimum practical switching time; can 
become a bottleneck 

■ Time for context switch is dependent on 
hardware support ( 1- 1000 microseconds). 
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CPU Switch From Process to 
Process 



executing 


operating system 
interrupt or system call 


► idle interrupt or system call 


save state into PCB 



reload state from PCB f 


process P : 


1 1 

save state into PCB 0 



• 

• 


- 

• 



reload state from PCB! 


J 


-idle 


executing 


idle 


Code executed in kernel above is overhead 
□ Overhead sets minimum practical switching time 


Schedulers 


■ Long-term scheduler (or job scheduler) - 

□ selects which processes should be brought into the ready 
queue. 

□ invoked very infrequently (seconds, minutes); may be slow. 

□ controls the degree of multiprogramming 

■ Short term scheduler (or CPU scheduler) - 

□ selects which process should execute next and allocates 
CPU. 

□ invoked very frequently (milliseconds) - must be very fast 

■ Medium Term Scheduler 

□ swaps out process temporarily 

□ balances load for better throughput 
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Medium Term (Time-sharing) 
Scheduler 
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Process Profiles 


■ I/O bound process - 

□ spends more time in I/O, short CPU bursts, CPU 
underutilized. 

■ CPU bound process - 

□ spends more time doing computations; few very long CPU 
bursts, I/O underutilized. 

■ The right job mix: 

□ Long term scheduler - admits jobs to keep load balanced 
between I/O and CPU bound processes 

□ Medium term scheduler - ensures the right mix (by 
sometimes swapping out jobs and resuming them later) 
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Process Creation 


■ Processes are created and deleted 
dynamically 

■ Process which creates another process is 
called a parent process; the created process 
is called a child process. 

■ Result is a tree of processes 

■ e.g. UNIX - processes have dependencies and form a 
hierarchy. 

■ Resources required when creating process 

■ CPU time, files, memory, I/O devices etc. 
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UNIX Process Hierarchy 
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What does it take to create a 
process? 

■ Must construct new PCB 

□ Inexpensive 

■ Must set up new page tables for address space 

□ More expensive 

■ Copy data from parent process? (Unix fork() ) 

□ Semantics of Unix fork() are that the child process gets 
complete copy of the parent memory and I/O state 

□ Originally very expensive 

□ Much less expensive with “copy on write” 

■ Copy I/O state (file handles, etc) 

□ Medium expense 



Process Creation 


■ Resource sharing 

□ Parent and children share all resources. 

□ Children share subset of parent’s resources - prevents 
many processes from overloading the system. 

□ Parent and children share no resources. 

■ Execution 

□ Parent and child execute concurrently. 

□ Parent waits until child has terminated. 

■ Address Space 

□ Child process is duplicate of parent process. 

□ Child process has a program loaded into it. 
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UNIX Process Creation 


■ Fork system call creates new processes 

■ execve system call is used after a fork to 
replace the processes memory space with 
new program. 



Process Termination 


■ Process executes last statement and asks 
the operating system to delete it (exit). 

□ Output data from child to parent (via wait). 

□ Process’ resources are deallocated by operating system. 

■ Parent may terminate execution of child 
processes. 

□ Child has exceeded allocated resources. 

□ Task assigned to child is no longer required. 

□ Parent is exiting 

- OS does not allow child to continue if parent terminates 
■ Cascading termination 
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Threads 


■ Processes do not share resources well 

□ high context switching overhead 

■ Idea: Separate concurrency from protection 

■ Multithreading: a single program made up of a number of 
different concurrent activities 

m A thread (or lightweight process) 

□ basic unit of CPU utilization; it consists of: 

program counter, register set and stack space 

■ A thread shares the following with peer threads: 

code section, data section and OS resources (open files, signals) 

No protection between threads 

■ Collectively called a task. 

■ Heavyweight process is a task with one thread. 
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Single and Multithreaded 
Processes 


code 

data 

files 




registers 

registers 

registers 

stack 

stack 

stack 
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code 


data 


files 


registers 


stack 


thread 


single-threaded process 


multithreaded process 


thread 


■ Threads encapsulate concurrency: “Active” component 

■ Address spaces encapsulate protection: “Passive” part 

□ Keeps buggy program from trashing the system 
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Benefits 

i Responsiveness 


■ Resource Sharing 

■ Economy 

■ Utilization of MP Architectures 
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Threads (Cont.) 

■ In a multi-threaded task, while one server 
thread is blocked and waiting, a second 
thread in the same task can run. 

■ Cooperation of multiple threads in the same job results 
in higher throughput and improved performance. 

■ Applications that require sharing a common buffer (i.e. 
producer-consumer) benefit from thread utilization. 

■ Threads provide a mechanism that allows 
sequential processes to make blocking 
system calls while also achieving parallelism. 
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Thread State 


State shared by all threads in process/addr 
space 

□ Contents of memory (global variables, heap) 

□ I/O state (file system, network connections, etc) 

State “private” to each thread 

□ Kept in TCB = Thread Control Block 

□ CPU registers (including, program counter) 

□ Execution stack 

■ Parameters, Temporary variables 

■ return PCs are kept while called procedures are 
executing 



Threads (cont.) 


■ Thread context switch still requires a register 
set switch, but no memory management 
related work! 

■ Thread states - 

■ ready, blocked, running, terminated 

m Threads share CPU and only one thread can 
run at a time. 

■ No protection among threads. 
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Examples: Multithreaded 
programs 


Embedded systems 

□ Elevators, Planes, Medical systems, Wristwatches 

□ Single Program, concurrent operations 

Most modern OS kernels 

□ Internally concurrent because have to deal with 
concurrent requests by multiple users 

□ But no protection needed within kernel 

Database Servers 

□ Access to shared data by many concurrent users 

□ Also background utility processing must be done 



More Examples: Multithreaded 
programs 


■ Network Servers 

□ Concurrent requests from network 

□ Again, single program, multiple concurrent operations 

□ File server, Web server, and airline reservation systems 

■ Parallel Programming (more than one physical CPU) 

□ Split program into multiple threads for parallelism 

□ This is called Multiprocessing 
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u =lt 

0 

> CD 

0) 0 
■ ■ Q_ 

# of addr 

spaces: 

One 

Many 

One 

MS/DOS, early 
Macintosh 

Traditional UNIX 

Many 

Embedded systems 
(Geoworks, VxWorks, 
JavaOS, etc) 

JavaOS, Pilot (PC) 

Mach, OS/2, Linux 

Win NT to XP, Solaris, 
HP-UX, OS X, 


Real operating systems have either 

□ One or many address spaces 

□ One or many threads per address space 
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Types of Threads 


■ Kernel-supported threads 

■ User-level threads 

■ Hybrid approach implements both user-level 
and kernel-supported threads (Solaris 2). 
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Kernel Threads 


■ Supported by the Kernel 

□ Native threads supported directly by the kernel 

□ Every thread can run or block independently 

□ One process may have several threads waiting on different things 


■ Downside of kernel threads: a bit expensive 

□ Need to make a crossing into kernel mode to schedule 


■ Examples 

□ Windows XP/2000, Solaris, Linux, Tru64 UNIX, 
Mac OS X, Mach, OS/2 
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User Threads 

■ Supported above the kernel, via a set of library calls 
at the user level. 

■ Thread management done by user-level threads library 

□ User program provides scheduler and thread package 

■ May have several user threads per kernel thread 

■ User threads may be scheduled non-preemptively relative to 
each other (only switch on yield()) 

□ Advantages 

■ Cheap, Fast 

□ Threads do not need to call OS and cause interrupts to kernel 

□ Disadv: If kernel is single threaded, system call from any 
thread can block the entire task. 

■ Example thread libraries: 

□ POSIX Pthreads, Win32 threads, Java threads 
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Multithreading Models 


■ Many-to-One 

■ One-to-One 

■ Many-to-Many 
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Many-to-One 

■ Many user-level threads mapped to single 
kernel thread 

■ Examples: 

□ Solaris Green Threads 

□ GNU Portable Threads 



36 


One-to-One 


■ Each user-level thread maps to kernel thread 



Examples 

□ Windows NT/XP/2000; Linux; Solaris 9 and later 
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Many-to-Many Model 


■ Allows many user level 
threads to be mapped to 
many kernel threads 

■ Allows the operating 
system to create a 
sufficient number of 
kernel threads 

■ Solaris prior to version 9 

. Windows NT/2000 with 
the ThreadFiber package 
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Thread Support in Solaris 2 

■ Solaris 2 is a version of UNIX with support for 

□ kernel and user level threads, symmetric multiprocessing 
and real-time scheduling. 

■ Lightweight Processes (LWP) 

□ intermediate between user and kernel level threads 

□ each LWP is connected to exactly one kernel thread 
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Threads in Solaris 2 


task 1 task 2 task 3 



CPU 








Two-level Model 


■ Similar to M:M, except that it allows a user 
thread to be bound to kernel thread 

■ Examples 

□ IRIX, HP-UX, Tru64 UNIX, Solaris 9 and earlier 
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Threading Issues 


■ Semantics of fork() and exec() system 
calls 

■ Thread cancellation 

■ Signal handling 

■ Thread pools 

■ Thread specific data 
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Semantics of fork() and exec() 

• Does fork() duplicate only the calling thread or all threads? 

• Some U NIXes have two versions of fork 

• exec() usually works as normal - replace the running 
process including all threads 



Signal Handling 

• Signals are used in UNIX systems to notify a process that 
particular event has occurred. 

• A signal handler is used to process signals 

1. Signal is generated by particular event 

2. Signal is delivered to a process 

3 . Signal is handled by one of two signal handlers: 

1. default 

2. user-defined 

• Every signal has default handler that kernel runs when 
handling signal 

• User-defined signal handler can override default 

• For single-threaded, signal delivered to process 



Signal Handling (Cont.) 

• Where should a signal be delivered for multi-threaded? 

• Deliver the signal to the thread to which the signal 
applies 

• Deliver the signal to every thread in the process 

• Deliver the signal to certain threads in the process 

• Assign a specific thread to receive all signals for the 
process 



Thread Cancellation 


• Terminating a thread before it has finished 

• Thread to be canceled is target thread 

• Two general approaches: 

• Asynchronous cancellation terminates the target thread 
immediately 

• Deferred cancellation allows the target thread to periodically 
check if it should be cancelled 



Thread Pools 


• Create a number of threads in a pool where they await work 

• Advantages: 

• Usually slightly faster to service a request with an existing 
thread than create a new thread 

• Allows the number of threads in the application(s) to be 
bound to the size of the pool 



Thread-Local Storage 

• Thread-local storage (TLS) allows each thread to have its 
own copy of data 

• Different from local variables 

• Local variables visible only during single function 
invocation 

• TLS visible across function invocations 



Multi (processing, programming, threading) 

■ Definitions: 

□ Multiprocessing = Multiple CPUs 

□ Multiprogramming = Multiple Jobs or Processes 

□ Multithreading = Multiple threads per Process 

■ What does it mean to run two threads “concurrently”? 

□ Scheduler is free to run threads in any order and interleaving: FIFO, Random, 

□ Dispatcher can choose to run each thread to completion or time-slice in big 
chunks or small chunks 


Multiprocessing 


Multiprogramming 


A 

B 

C 






B 




H 
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Interprocess Communication 


• Processes within a system may be independent or cooperating 

• Cooperating process can affect or be affected by other processes, 
including sharing data 

• Reasons for cooperating processes: 

• Information sharing 

• Computation speedup 

• Modularity 

• Convenience 

• Cooperating processes need interprocess communication (IPC) 

• Two models of IPC 

• Shared memory 

• Message passing 
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Interprocess Communication 

Shared Memory 

• An area of memory shared among the processes that wish 
to communicate 

• The communication is under the control of the processes 
not the operating system. 

• Major issues is to provide mechanism that will allow the 
user processes to synchronize their actions when they 
access shared memory. 

• Synchronization is discussed in great details in Chapter 5. 



Interprocess Communication 

Shared Memory 



process A 
shared memory 

process B 


kernel 


Producer-Consumer Problem 


• Paradigm for cooperating processes, producer process 
produces information that is consumed by a consumer 
process 

• unbounded-buffer places no practical limit on the size 
of the buffer 

• bounded-buffer assumes that there is a fixed buffer 
size 


53 



Bounded-Buffer - 
Shared-Memory Solution 

• Shared data 

#def ine BUFFER_SIZE 10 
typedef struct { 

} item; 

item buffer [BUFFER_SIZE] ; 
int in = 0; 
int out = 0; 


54 



Bounded-Buffer - Producer 


item next produced; 
while (true) { 

/* produce an item in next produced */ 
while (((in + 1) % BUFFER_SIZE) == out) 

; /* do nothing */ 
buffer [in] = next produced; 
in = (in + 1) % BUFFER_SIZE; 

} 
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Bounded Buffer - Consumer 

item next consumed; 

while (true) { 

while (in == out) 

; /* do nothing */ 

next consumed = buffer [out]; 

out = (out +1) % BUFFER_SIZE; 

/* consume the item in next consumed */ 

} 
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Bounded-Buffer - 
Shared-Memory Solution 

• How many elements in the buffer can be used at most at a given time? 


item next produced; 
while (true) { 

/* produce an item in next produced */ 
while (((in + 1) % BUFFER_SIZE ) == out) 

; /* do nothing */ 

buffer [in] = next_produced; 
in = (in + 1) % BUFFER_SIZE ; 

} 


item next_consumed; 

while (true) { 

while (in == out) 

; /* do nothing */ 

next_consumed = buffer [out]; 

out = (out +1) % BUFFER_SIZE ; 

/* consume the item in next 
consumed */ 

} 


Producer 


Consumer 
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Bounded-Buffer - 
Shared-Memory Solution 

• Solution is correct, but can only use BUFFER_SIZE-1 elements 
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Interprocess Communication 

Message Passing 

• Mechanism for processes to communicate and to synchronize 
their actions 

• Message system - processes communicate with each other 
without resorting to shared variables 

• I PC facility provides two operations: 

• send (message) 

• recei ve(message) 

• The message size is either fixed or variable 



Interprocess Communication 

Message Passing 
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Message Passing (Cont.) 


• If processes P and Q wish to communicate, they need to: 

• Establish a communication link between them 

• Exchange messages via send/receive 

• Implementation issues: 

• How are links established? 

• Can a link be associated with more than two processes? 

• How many links can there be between every pair of 
communicating processes? 

• What is the capacity of a link? 

• Is the size of a message that the link can accommodate fixed or 
variable? 

• Is a link unidirectional or bi-directional? 
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Message Passing (Cont.) 

• Implementation of communication link 
• Physical: 

- Shared memory 

- Hardware bus 

- Network 
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Direct Communication 


Processes must name each other explicitly: 

• send (P, message) - send a message to process P 

• receive(Q, message) - receive a message from process Q 
Properties of communication link 

• Links are established automatically 

• A link is associated with exactly one pair of communicating 
processes 

• Between each pair there exists exactly one link 

• The link may be unidirectional, but is usually bi-directional 



Indirect Communication 


• Messages are directed and received from mailboxes (also referred 
to as ports) 

• Each mailbox has a unique id 

• Processes can communicate only if they share a mailbox 

• Properties of communication link 

• Link established only if processes share a common mailbox 

• A link may be associated with many processes 

• Each pair of processes may share several communication links 

• Link may be unidirectional or bi-directional 
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Indirect Communication 


Operations 

• create a new mailbox (port) 

• send and receive messages through mailbox 

• destroy a mailbox 
Primitives are defined as: 

send(A message) - send a message to mailbox A 
receive(A message) - receive a message from mailbox A 



Indirect Communication 


Mailbox sharing 

• P v P 2 , and P 3 share mailbox A 

• P v sends; P 2 and P 3 receive 

• Who gets the message? 

Solutions 

• Allow a link to be associated with at most two processes 

• Allow only one process at a time to execute a receive 
operation 

• Allow the system to select arbitrarily the receiver. 

Sender is notified who the receiver was. 



Synchronization 

Message passing may be either blocking or non-blocking 
Blocking is considered synchronous 

• Blocking send -- the sender is blocked until the message is 
received 

• Blocking receive -- the receiver is blocked until a message 
is available 

Non-blocking is considered asynchronous 

• Non-blocking send -- the sender sends the message and 
continue 

• Non-blocking receive -- the receiver receives: 

• A valid message, or 

• Null message 
Different combinations possible 

• If both send and receive are blocking, we have a rendezvous 



Message passing (Cont.) 

• Producer-consumer becomes trivial 


message next produced; 
while (true) { 

/* produce an item in next produced */ 

Producer 

send (next_produced) ; 

} 


message next consumed; 
while (true) { 

receive (next consumed) ; 


Consumer 


/* consume the item in next consumed */ 

} 
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Buffering 


Queue of messages attached to the link, 
implemented in one of three ways 

1 . Zero capacity - no messages are queued on a link. 
Sender must wait for receiver (rendezvous) 

2. Bounded capacity - finite length of n messages 
Sender must wait if link full 

3. Unbounded capacity - infinite length 
Sender never waits 



Examples of IPC Systems - POSIX 

• POSIX Shared Memory 

• Process first creates shared memory segment 

shm_fd = shm_open (name , O CREAT | O RDWR, 0666) ; 

• Also used to open an existing segment to share it 

• Set the size of the object 

f truncate (shm fd, 4096); 

• Now the process could write to the shared memory 

sprintf (shared memory, "Writing to shared 
memory") ; 
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IPC POSIX Producer 


#include <stdio.h> 

#include <stdlib.h> 

#include <string.h> 

#include <fcntl.h> 

#include <sys/shm.h> 
tinclude <sys/stat.h> 

int mainO 

{ 

/* the size (in bytes) of shared memory object */ 
const int SIZE = 4096; 

/* name of the shared memory object */ 
const char *name = "OS"; 

/* strings written to shared memory */ 
const char ^message 0 = "Hello"; 
const char *message_l = "World!"; 

/* shared memory file descriptor */ 
int shmJd; 

/* pointer to shared memory obect */ 
void *ptr; 

/* create the shared memory object */ 
shmJd = shm_open(name, O^CREAT I OJIDWR, 0666); 

/* configure the size of the shared memory object */ 
ftruncate(shmfd, SIZE); 

/* memory map the shared memory object */ 

ptr = mmap(0, SIZE, PR0T_WRITE, MAP ^SHARED, shm.fd, 0); 

/* write to the shared memory object */ 

sprintf (ptr,"*/, s" .message 0); 

ptr += strlen (message 0); 

sprintf (ptr , "*/,s" .message -1) ; 

ptr += strlen (message,!.) ; 

return 0; 


} 
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IPC POSIX Consumer 

#include <stdio.h> 

#include <stdlib.h> 

#include <fcntl.li> 

#include <sys/shm.h> 

#include <sys/stat.h> 

int main() 

{ 

/* the size (in bytes) of shared memory object */ 
const int SIZE = 4096; 

/* name of the shared memory object */ 
const char *name = "OS"; 

/* shared memory file descriptor */ 
int shmjfd; 

/* pointer to shared memory obect */ 
void *ptr; 

/* open the shared memory object */ 
shm fd = shm open (name, 0 RDONLY, 0666); 

/* memory map the shared memory object */ 

ptr = mmap(0, SIZE, PROTREAD, MAP SHARED, shm fd, 0); 

/* read from the shared memory object */ 
printf C7,s" , (char *)ptr); 

/* remove the shared memory object */ 
shm _unl ink (name) ; 

return 0; 


} 
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Examples of I PC Systems - Mach 

• Mach communication is message based 

• Even system calls are messages 

• Each task gets two mailboxes at creation- Kernel and Notify 

• Only three system calls needed for message transfer 

msg_send ( ) , msg_receive ( ) , msg_rpc ( ) 

• Mailboxes needed for communication, created via 

port_allocate ( ) 

• Send and receive are flexible, for example four options if mailbox full: 

- Wait indefinitely 

- Wait at most n milliseconds 

- Return immediately 

- Temporarily cache a message 
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Examples of I PC Systems 

Windows 

Message-passing centric via advanced local procedure call 
(LPC) facility 

• Only works between processes on the same system 

• Uses ports (like mailboxes) to establish and maintain 
communication channels 

• Communication works as follows: 

- The client opens a handle to the subsystem’s 

connection port object. 

- The client sends a connection request. 

- The server creates two private communication ports 
and returns the handle to one of them to the client. 

- The client and server use the corresponding port 
handle to send messages or callbacks and to listen for 
replies. 



Local Procedure Calls in 

Windows 


Client 



Server 








Communications in Client-Server 

Systems 

• Sockets 

• Remote Procedure Calls 

• Pipes 
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Sockets 


A socket is defined as an endpoint for communication 

Concatenation of IP address and port - a number included at 
start of message packet to differentiate network services on a 
host 

The socket 161.25.19.8:1625 refers to port 1625 on host 
161.25.19.8 

Communication consists between a pair of sockets 

All ports below 1024 are well known, used for standard 
services 

Special IP address 127.0.0.1 (loopback) to refer to system on 
which process is running 



Socket Communication 


host X 

( 146 . 86 . 5 . 20 ) 



Sockets in Java 


• Three types of sockets 

• Connection-oriented 
(TCP) 

• Connectionless (UDP) 

• MulticastSocket class- 
data can be sent to 
multiple recipients 


• Consider this “Date” server: 


import java.net.*; 
import java.io.*; 

public class DateServer 

{ 

public static void main(String[] args) { 
try { 

ServerSocket sock = new ServerSocket(6013) ; 

/* now listen for connections */ 
while (true) { 

Socket client = sock. accept () ; 

Print Writer pout = new 
PrintWriter(client.getOutputStream() , true) ; 

/* write the Date to the socket */ 

pout. println (new java. util. Date () .toStringO) ; 

/* close the socket and resume */ 

/* listening for connections */ 
client. close () ; 

} 

} 

catch (IOException ioe) { 

System. err . println (ioe) ; 

} 

} 

} 
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Remote Procedure Calls 


Remote procedure call (RPC) abstracts procedure calls 
between processes on networked systems 

• Again uses ports for service differentiation 

Stubs - client-side proxy for the actual procedure on the 
server 

The client-side stub locates the server and marshalls the 
parameters 

The server-side stub receives this message, unpacks the 
marshalled parameters, and performs the procedure on the 
server 

On Windows, stub code compile from specification written in 

Microsoft Interface Definition Language (MIDL) 



Remote Procedure Calls (Cont.) 


• Data representation handled via External Data 
Representation (XDL) format to account for different 
architectures 

• Big-endian and little-endian 

• Remote communication has more failure scenarios than local 

• Messages can be delivered exactly once rather than at 

most once 

• OS typically provides a rendezvous (or matchmaker) service 
to connect client and server 
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Execution of RPC 


client 


messages 


server 












Pipes 

Acts as a conduit allowing two processes to communicate 

Ordinary pipes - cannot be accessed from outside the 
process that created it. Typically, a parent process creates a 
pipe and uses it to communicate with a child process that it 
created. 

Named pipes - can be accessed without a parent-child 
relationship. 


Ordinary Pipes 


• Ordinary Pipes allow communication in standard producer-consumer 
style 

• Producer writes to one end (the write-end of the pipe) 

• Consumer reads from the other end (the read-end of the pipe) 

• Ordinary pipes are therefore unidirectional 

• Require parent-child relationship between communicating processes 


parent 

fd[0] fd[1] 


child 

fd[0] fd[1] 



pipe 



• Windows calls these anonymous pipes 

• See Unix and Windows code samples in textbook 
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#def ine READ_END 0 
#def ine WRITE_END 1 
int main (void) 

{ 


Ordinary Pipes 

(see full example in the book) 


char write_msg [BUFFER_SIZE] = "Greetings"; 
char read_msg [BUFFER_SIZE] ; 
int fd [2 ] ; 
pid_t pid; 


if (pipe(fd) == -1) { 

/* handle error */ 

} 

pid = fork ( ) ; 

if (pid < 0) { 

/* handle error */ 

} 

If (pid >0) { /* parent process */ 

close (fd [READ_END] ) ; 

write ( fd [WRITE_END] , write_msg, strlen (write_msg) + 1); 
close (fd [WRITE_END] ) ; 

} else { /* child process */ 
close (fd [WRITE_END] ) ; 

read (fd [READ_END] , read_msg, BUFFER_SIZE) ; 
printf ("read %s" , read_msg) ; 
close (fd [READ_END] ) ; 

} 

return 0; 


} 
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Named Pipes 


Named Pipes are more powerful than ordinary pipes 

Communication is bidirectional 

No parent-child relationship is necessary between the 
communicating processes 

Several processes can use the named pipe for communication 
Provided on both UNIX and Windows systems 
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Outline 


• Basic Concepts 

• Scheduling Objectives 

• Levels of Scheduling 

• Scheduling Criteria 

• Scheduling Algorithms 

• FCFS, Shortest Job First, Priority, Round Robin, Multilevel 

• Multiple Processor Scheduling 

• Real-time Scheduling 

• Algorithm Evaluation 



Basic Concepts 


• Maximum CPU utilization 
obtained with 
multiprogramming. 

• CPU-I/O Burst Cycle 

• Process execution consists of a cycle 
of CPU execution and I/O wait. 


load store 
add store 
read from file 


wait for I/O 


store increment 

index 

write to file 


wait for I/O 


load store 
add store 
read from file 


wait for I/O 


“\ 


> CPU burs 


< 


y I/O burst 


CPU burs 


I/O burst 


y CPU burs 


< 


> I/O burst 




CPU Burst Distribution 



burst duration (milliseconds) 


Scheduling Objectives 

• Enforcement of fairness 

o in allocating resources to processes 

• Enforcement of priorities 

• Make best use of available system resources 

• Give preference to processes holding key 
resources. 

• Give preference to processes exhibiting good 
behavior. 

• Degrade gracefully under heavy loads. 



Issues to consider in scheduling 

• I/O boundedness 

o short burst of CPU before blocking for I/O 

• CPU boundedness 

o extensive use of CPU before blocking for I/O 

• Urgency and Priorities 

• Frequency of preemption 

• Process execution time 

• Time sharing 

o amount of execution time process has already received. 
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Levels of Scheduling 

• High Level Scheduling or Job Scheduling 

o Selects jobs allowed to compete for CPU and other system 
resources. 

• Intermediate Level Scheduling or Medium Term 
Scheduling 

o Selects which jobs to temporarily suspend/resume to smooth 
fluctuations in system load. 

• Low Level (CPU) Scheduling or Dispatching 

o Selects the ready process that will be assigned the CPU. 
o Ready Queue contains PCBs of processes. 



Levels of Scheduling (cont.) 

Job entry 


Job initiation V High level scheduling 



job completion I5T 
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CPU Scheduler 


• Selects from among the processes in memory that 
are ready to execute, and allocates the CPU to 
one of them. 

• Non-preemptive Scheduling 

• Once CPU has been allocated to a process, the process keeps 
the CPU until 

• Process exits OR 

• Process switches to waiting state 

• Preemptive Scheduling 

• Process can be interrupted and must release the CPU. 

• Need to coordinate access to shared data 
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CPU scheduling decisions 

• CPU scheduling decisions may take place when a 
process: 

• switches from running state to waiting state 

• switches from running state to ready state 

• switches from waiting to ready 

• terminates 

• Scheduling under 1 and 4 is non-preemptive. 

• All other scheduling is preemptive. 
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CPU scheduling decisions 



Dispatcher 

• Dispatcher module gives control of the CPU to the 
process selected by the short-term scheduler. 

This involves: 

• switching context 

• switching to user mode 

• jumping to the proper location in the user program to restart that 
program 

• Dispatch Latency: 

• time it takes for the dispatcher to stop one process and start 
another running. 

• Dispatcher must be fast. 
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Scheduling Criteria 

• CPU Utilization 

• Keep the CPU and other resources as busy as possible 

• Throughput 

• # of processes that complete their execution per time unit. 

• Turnaround time 

• amount of time to execute a particular process from its entry 
time. 
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Scheduling Criteria (cont.) 

• Waiting time 

• amount of time a process has been waiting in the ready queue. 

• Response Time (in a time-sharing environment) 

• amount of time it takes from when a request was submitted until 
the first response is produced, NOT output. 
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Optimization Criteria 

• Max CPU Utilization 

• Max Throughput 

• Min Turnaround time 

• Min Waiting time 

• Min response time 
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First-Come, First-Served (FCFS) 
Scheduling 

• Policy: Process that requests the CPU FIRST 
allocated the CPU FIRST. 

• FCFS is a non-preemptive algorithm. 

• Implementation - using FIFO queues 

• incoming process is added to the tail of the queue. 

• Process selected for execution is taken from head of queue. 

• Performance metric - Average waiting time in 
queue. 

• Gantt Charts are used to visualize schedules. 



First-Come, First-Served (FCFS) 
Scheduling 


• Example 


Process 

Burst Time 

PI 

24 

P2 

3 

P3 

3 


Gantt Chart for Schedule 


PI 

P2 

P3 





24 27 30 


• Suppose the arrival order 
for the processes is 

• PI, P2, P3 

• Waiting time 

• PI =0; 

• P2 = 24; 

• P3 = 27; 

• Average waiting time 

• (0+24+27)/3 = 1 7 
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FCFS Scheduling (cont.) 


• Example 


Process 

Burst Time 

PI 

24 

P2 

3 

P3 

3 


Gantt Chart for Schedule 


P2 

P3 

PI 





0 


30 


Suppose the arrival order 

for the processes is 

• P2, P3, PI 

Waiting time 

• PI = 6; P2 = 0; P3 = 3; 

Average waiting time 

• (6+0+3)/3 = 3 , better.. 

Convoy Effect: 

• short process behind long 
process, e.g., 1 CPU bound 
process, many I/O bound 
processes. 
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Shortest-Job-First (SJF) Scheduling 

• Associate with each process the length of its next CPU 
burst. Use these lengths to schedule the process with 
the shortest time. 

• Two Schemes: 

• Scheme 1: Non-preemptive 

• Once CPU is given to the process it cannot be preempted until it 
completes its CPU burst. 

• Scheme 2: Preemptive 

• If a new CPU process arrives with CPU burst length less than 
remaining time of current executing process, preempt. Also called 
Shortest-Remaining-Time-First (SRTF). 

• SJF is optimal - gives minimum average waiting time for a given 
set of processes. 

• The difficulty is knowing the length of the next CPU request 

• Could ask the user 



Non-Preemptive SJF Scheduling 

• Example 


Process 

Arrival Time 

Burst Time 

PI 

0 

7 

P2 

2 

4 

P3 

4 

1 

P4 

5 

4 


Gantt Chart for Schedule 


pi 

P3 

P2 

P4 






78 12 16 


Average waiting time = 
(0+6+3+7)/4 = 4 
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Non-Preemptive SJF Scheduling 

Process Arrival Time Burst Time 


P, 0 6 
P 2 2 8 
P, 5 7 
P 4 0 3 


• SJF scheduling chart 


p 4 

Pi 

P 3 

p 2 

03 9 16 24 


• Average waiting time = (3 + 16 + 9 + 0)/4 = 7 

• Average turnaround time = ((9-0) + (24-2) + (16-7) + (3-0))/4 = 10.75 
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Preemptive SJF Scheduling (SRTF) 

• Example 


Process 

Arrival Time 

Burst Time 

PI 

0 

7 

P2 

2 

4 

P3 

4 

1 

P4 

5 

4 


Gantt Chart for Schedule 


pi 

P2 

P3 

P2 

P4 

PI 

0 2 

4 


; 

1 

1 

16 


Average waiting time = 
(9+l+0+2)/4 = 3 
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Preemptive SJF Scheduling (SRTF) 

• Now we add the concepts of varying arrival times and preemption to the 
analysis 

Process Arrival Time Burst Time 

P 1 0 8 

P 2 1 4 

P ' 2 9 

P 4 3 5 

• Preemptive SJF Gantt Chart 



Pi 

p 2 

p 4 

Pi 

p 3 

0 1 5 

0 1 

1 

7 2 


• Average waiting time = [(10-1)+(1-1)+(17-2)+5-3)]/4 = 26/4 = 6.5 msec 

• Average turnaround time = ((17-0) + (5-1) + (26-2) + (10-3))/4 = 13 msec 
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Determining Length of Next CPU Burst 

• One can only estimate the length of burst. 

• Use the length of previous CPU bursts and 
perform exponential averaging. 

• t n = actual length of nth burst 

• T/7+1 = predicted value for the next CPU burst 

• a = 0, 0 < a < 1 

• Define 

• Tn +1 = a tn + (1- a) Tn 
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Prediction of the length of the next CPU 
burst 


12 h 

I, 10 

8 h 

h 6 


4 - 


time 


CPU burst (§ 6 4 6 4 13 13 13 

"guess" (t/) 10 8 6 6 5 9 11 12 
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Exponential Averaging(cont.) 

• a = 0 

• T/7+1 = T n, Recent history does not count 

• a= 1 

• Tn+i = t/?; Only the actual last CPU burst counts. 

• Similarly, expanding the formula: 

• T/ 7+1 = atn + (1-a) atn-i + ...+ (1-a) A j atn-y + ... + (1-a) A (r?+1) To 

• Each successive term has less weight than its predecessor. 

• Commonly, a is set to 0.5 
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Priority Scheduling 

• A priority value (integer) is associated with each 
process. Can be based on 

o Cost to user 
o Importance to user 
o Aging 

o %CPU time used in last X hours. 

• CPU is allocated to the process with the highest 
priority. 

o Preemptive 
o Nonpreemptive 
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Priority Scheduling (cont.) 

• SJF is a priority scheme where the priority is the 
predicted next CPU burst time. 

• Problem 

• Starvation!! - Low priority processes may never execute. 

• Solution 

• Aging - as time progresses increase the priority of the process. 
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Priority Scheduling - Non-preemptive 


ProcessA 

Burst Time 

Priority 

p, 

10 

3 

P 2 

1 

1 

P 3 

2 

4 

P 4 

1 

5 

P 5 

5 

2 

Priority scheduling Gantt Chart 



P 2 

P 5 

P 1 

P 3 

P 4 


01 6 16 18 19 


• Average waiting time = 8.2 msec 
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Priority Scheduling - Preemptive 


ProcessA 

Burst Time 

Priority 

Arrival Time 

p, 

6 

3 

12 

P 2 

8 

2 

0 

P 3 

7 

4 

4 

P 4 

3 

1 

2 

P 5 

Gantt Chart 

5 

5 

30 


P2 

P4 

P2 

P3 

PI 

P3 


P5 

0 2 


5 1] 

1 

2 1 

8 2 

4 2 

0 35 


• Average waiting time = [0+3+(7+6)+0+0)]/5 = 16/5 = 3.2 msec 

• Average turnaround time = (6 + 11 + 20 + 3 + 5)/5 = 45/5 = 9 msec 

• Average response time (assuming immediate response by a process when 
executed) = (0 + 0 + 7 + 0 + 0)/5 = 1.4 msec 

• CPU utilization = 29 / 35 = 0.83 = 83% 

• Throughput = 5 / 35 = 0.14 #process/msec 
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Round Robin (RR) 

• Each process gets a small unit of CPU time 

• Time quantum usually 10-100 milliseconds. 

• After this time has elapsed, the process is preempted and added 
to the end of the ready queue. 

• n processes, time quantum = q 

• Each process gets 1 1n CPU time in chunks of at most q time units 
at a time. 

• No process waits more than (n-1)g time units. 

• Performance 

- Time slice q too large - FIFO behavior 

- Time slice q too small - Overhead of context switch is too expensive. 

- Heuristic - 70-80% of jobs block within timeslice 
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Round Robin Example 

• Time Quantum = 20 


Process 

Burst Time 

PI 

53 

P2 

17 

P3 

68 

P4 

24 


Gantt Chart for Schedule 


pi 

P2 

P3 

P4 

PI 

P3 

P4 

pi 

P3 

P3 

2( 

3' 

5' 

; 

7 5 

7 1] 

7 i: 

i i: 

4 1 

54 1( 


Typically, higher average turnaround time than SRTF, but better response 


32 


Round Robin Example 

Process Burst Time 
P 1 24 
P 2 3 

P 3 3 

• The Gantt chart is: 



Pi 

p 2 

p 3 

Pi 

Pi 

Pi 

Pi 

Pi 


0 4 7 10 14 18 22 26 30 

• Average waiting time = (6 + 4 + 7)/3 = 5.67 

• Average turnaround time = (30 + 7 + 1 0)/3 = 11 .75 
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Time Quantum and Context Switch Time 


process time = 10 



quantum 

12 


6 


1 


context 

switches 

0 


1 


9 
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average turnaround time 


Turnaround Time Varies With The Time Quantum 


12.5 
12.0 

11.5 
11.0 

10.5 
10.0 

9.5 

9.0 


1 2 3 4 5 6 7 

time quantum 




80% of CPU bursts 
should be shorter than 




Multilevel Queue 

• Ready Queue partitioned into separate queues 

o Example: system processes, foreground (interactive), background 
(batch), student processes.... 

• Each queue has its own scheduling algorithm 

o Example: foreground (RR), background (FCFS) 

• Processes assigned to one queue permanently. 

• Scheduling must be done between the queues 

o Fixed priority - serve all from foreground, then from background. 
Possibility of starvation. 

o Time slice - Each queue gets some CPU time that it schedules - e.g. 80% 
foreground (RR), 20% background (FCFS) 
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Multilevel Queues 
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Multilevel Feedback Queue 

• Multilevel Queue with priorities 

• A process can move between the queues. 

o Aging can be implemented this way. 

• Parameters for a multilevel feedback queue 
scheduler: 

o number of queues, 
o scheduling algorithm for each queue, 
o method used to determine when to upgrade a process, 
o method used to determine when to demote a process. 

o method used to determine which queue a process will enter when that 
process needs service. 
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Multilevel Feedback Queue 

• Example: Three Queues - 

o QO - time quantum 8 milliseconds (FCFS) 
o Q1 - time quantum 16 milliseconds (FCFS) 
o Q2 - FCFS 

• Scheduling 

o New job enters QO - When it gains CPU, it receives 8 milliseconds. If job 
does not finish, move it to Q1 . 

o At Q1 , when job gains CPU, it receives 16 more milliseconds. If job does 
not complete, it is preempted and moved to queue Q2. 


39 



Multilevel Feedback Queues 
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Thread Scheduling 


• Distinction between user-level and kernel-level threads 

• When threads supported, threads scheduled, not processes 

• Many-to-one and many-to-many models, thread library schedules 
user-level threads to run on LWP 

• Known as process-contention scope (PCS) since scheduling 
competition is within the process 

• Typically done via priority set by programmer 

• Kernel thread scheduled onto available CPU is system-contention 
scope (SCS) - competition among all threads in system 
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Multiple-Processor Scheduling 

• CPU scheduling becomes more complex when 
multiple CPUs are available. 

o Have one ready queue accessed by each CPU. 

• Self scheduled - each CPU dispatches a job from ready Q 

• Master-Slave - one CPU schedules the other CPUs 

• Symmetric multiprocessing (SMP) 

o Homogeneous processors within multiprocessor 

o Each processor is self-scheduling, all processes in common ready 
queue, or each has its own private queue of ready processes 

o Currently, most common 
o Permits Load Sharing 

• Asymmetric multiprocessing 

o only 1 CPU runs kernel, others run user programs 
o alleviates need for data sharing 



NUMA and CPU Scheduling 



computer 


Note that memory-placement algorithms can also consider affinity 
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Multicore Processors 


• Recent trend to place multiple processor cores on same 
physical chip 

• Faster and consumes less power 

• Multiple threads per core also growing 

• Takes advantage of memory stall to make progress on 
another thread while memory retrieve happens 
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Multithreaded Multicore System 
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Real-Time Scheduling 

• Hard Real-time Computing - 

o required to complete a critical task within a guaranteed amount of time. 

• Soft Real-time Computing - 

o requires that critical processes receive priority over less fortunate ones. 

• Types of real-time Schedulers 

o Periodic Schedulers - Fixed Arrival Rate 
o Demand-Driven Schedulers - Variable Arrival Rate 
o Deadline Schedulers - Priority determined by deadline 

o 
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Issues in Real-time Scheduling 

• Dispatch Latency 

o Problem - Need to keep dispatch latency small, OS may enforce process 
to wait for system call or I/O to complete. 

o Solution - Make system calls preemptible, determine safe criteria such 
that kernel can be interrupted. 

• Priority Inversion and Inheritance 

o Problem: Priority Inversion 

■ Higher Priority Process needs kernel resource currently being used by 
another lower priority process. .higher priority process must wait. 

o Solution: Priority Inheritance 

■ Low priority process now inherits high priority until it has completed use of the 
resource in question. 
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Real-time Scheduling - Dispatch Latency 
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Operating System Examples 


• Linux scheduling 
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Linux Scheduling Through Version 2.5 


• Prior to kernel version 2.5, ran variation of standard UNIX 
scheduling algorithm 

• Version 2.5 moved to constant order 0(1) scheduling time 

• Preemptive, priority based 

• Two priority ranges: time-sharing and real-time 

• Real-time range from 0 to 99 and nice value from 100 to 140 

• Map into global priority with numerically lower values indicating higher 
priority 

• Higher priority gets larger q 

• Task run-able as long as time left in time slice (active) 

• If no time left (expired), not run-able until all other tasks use their slices 

• All run-able tasks tracked in per-CPU runqueue data structure 

- Two priority arrays (active, expired) 

- Tasks indexed by priority 

- When no more active, arrays are exchanged 

• Worked well, but poor response times for interactive processes 
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Linux Scheduling in Version 2.6.23 + 


• Completely Fair Scheduler (C F S) 

• Scheduling classes 

• Each has specific priority 

• Scheduler picks highest priority task in highest scheduling class 

• Rather than quantum based on fixed time allotments, based on proportion of CPU 
time 

• 2 scheduling classes included, others can be added 

1. default 

2 . real-time 

• Quantum calculated based on nice value from -20 to +19 

• Lower value is higher priority 

• Calculates target latency - interval of time during which task should run at least 
once 

• Target latency can increase if say number of active tasks increases 

• CFS scheduler maintains per task virtual run time in variable vruntime 

• Associated with decay factor based on priority of task - lower priority is higher 
decay rate 

• Normal default priority yields virtual run time = actual run time 

• To decide next task to run, scheduler picks task with lowest virtual run time 
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CFS Performance 


The Linux CFS scheduler provides an efficient algorithm for selecting which 
task to run next. Each runnable task is placed in a red-black tree — a balanced 
binary search tree whose key is based on the value of vruntime. This tree is 
shown below: 



When a task becomes runnable, it is added to the tree. If a task on the 
tree is not runnable (for example, if it is blocked while waiting for I/O), it is 
removed. Generally speaking, tasks that have been given less processing time 
(smaller values of vruntime) are toward the left side of the tree, and tasks 
that have been given more processing time are on the right side. According 
to the properties of a binary search tree, the leftmost node has the smallest 
key value, which for the sake of the CFS scheduler means that it is the task 
with the highest priority. Because the red-black tree is balanced, navigating 
it to discover the leftmost node will require 0(lgN) operations (where N 
is the number of nodes in the tree). However, for efficiency reasons, the 
Linux scheduler caches this value in the variable rb_leftmost, and thus 
determinine which task to run next reauires onlv retrievine the cached value. 
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Algorithm Evaluation 

• Deterministic Modeling 

o Takes a particular predetermined workload and defines the performance 
of each algorithm for that workload. Too specific, requires exact 
knowledge to be useful. 

• Queuing Models and Queuing Theory 

o Use distributions of CPU and I/O bursts. Knowing arrival and service 
rates - can compute utilization, average queue length, average wait time 
etc... 

o Little’s formula - n = A*W where n is the average queue length, A is the 
avg. arrival rate and W is the avg. waiting time in queue. 

• Other techniques: Simulations, Implementation 
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Outline 


• Part 1 : 

• The Critical Section Problem 

• Synchronization Hardware 

• Semaphores 

• Part 2: 

• Classical Problems of Synchronization 

• Monitors 



Producer-Consumer Problem 


• Paradigm for cooperating processes; 

• producer process produces information that is 
consumed by a consumer process. 

• We need buffer of items that can be filled by 
producer and emptied by consumer. 

• Unbounded-buffer places no practical limit on the size of the buffer. 
Consumer may wait, producer never waits. 

• Bounded-buffer assumes that there is a fixed buffer size. Consumer 
waits for new item, producer waits if buffer is full. 

• Producer and Consumer must synchronize. 



Bounded Buffer using IPC (message 
passing) 


message next produced; 
while (true) { 

/* produce an item in next produced */ 
send (next_produced) ; 

} 


message next consumed; 
while (true) { 

receive (next consumed) ; 

/* consume the item in next consumed */ 

} 


Producer 


Consumer 


Bounded Buffer - Shared Memory 
Solution 


• Shared data 

#def ine BUFFER_SIZE 10 
typedef struct { 

} item; 

item buffer [BUFFER_SIZE] ; 
int in = 0; 
int out = 0; 



Bounded Buffer - Shared Memory 
Solution: producer 


item next produced; 
while (true) { 

/* produce an item in next produced */ 
while (((in + 1) % BUFFER_SIZE) == out) 

; /* do nothing */ 
buffer [in] = next produced; 
in = (in + 1) % BUFFER SIZE; 



Bounded Buffer - Shared Memory 
Solution: consumer 


item next consumed; 

while (true) { 

while (in == out) 

; /* do nothing */ 
next consumed = buffer [out]; 

out = (out + 1) % BUFFER SIZE; 


/* consume the item in next consumed */ 


} 



Shared data 


• Concurrent access to shared data may result in 
data inconsistency. 

• Maintaining data consistency requires 
mechanisms to ensure the orderly execution of 
cooperating processes. 

• Shared memory solution to the bounded-buffer 
problem allows at most (n-1) items in the buffer 
at the same time. 



Bounded Buffer 

• A solution that uses all N buffers is not that 
simple. 

• Modify producer-consumer code by adding a variable 
counter, initialized to 0, incremented each time a new item is 
added to the buffer 

• Shared data 

#def ine BUFFER_SIZE 10 
typedef struct { 


} item; 

item buffer [BUFFER_SIZE] ; 
int in = 0; 
int out = 0; 


int counter 


0 ; 



Bounded Buffer - Shared Memory 
Solution: producer 


item next produced; 
while (true) { 

/* produce an item in next produced */ 

while (counter == BUFFER_SIZE) ; 

/* do nothing */ 
buffer [in] = next produced; 
in = (in + 1) % BUFFER_SIZE; 

counter++; 


} 



Bounded Buffer - Shared Memory 
Solution: consumer 

item next consumed; 
while (true) { 

while (counter == 0) 

; /* do nothing */ 

next consumed = buffer [out]; 

out = (out +1) % BUFFER_SIZE; 

counter-- ; 

/* consume the item in next consumed */ 

} 



Bounded Buffer 


• The statements 

counter++; 

counter--; 

must be executed atomically. 

• Atomic Operations 

• An operation that runs to completion or not at all. 



Race Condition 


counter++ could be implemented as 


registerl = counter 
registerl = registerl + 1 
counter = registerl 

counter-- could be implemented as 


register2 = counter 
register2 = register2 - 1 
counter = register2 

Consider this execution interleaving with “count = I i 

SO: producer execute registerl = counter 
SI: producer execute registerl = registerl + 
S2: consumer execute register2 = counter 
S3: consumer execute register2 = register2 - 
S4: producer execute counter = registerl 
S5: consumer execute counter = register2 


i” initially: 

{registerl = 5} 
1 {registerl = 6} 
{register2 = 5} 

■ 1 {register2 = 4} 
{counter = 6 } 
{counter = 4} 



Race Condition 


If threads are working on separate data, scheduling doesn’t matter: 

Thread A Thread B 
x=1; y = 2; 

However, What about (Initially, y = 12): 

Thread A Thread B 
x = 1; y = 2; 
x = y+1; y = y*2; 

• What are the possible values of x? 

Or, what are the possible values of x below? 

Thread A Thread B 
x = 1; x = 2; 

• X could be non-deterministic (1 , 27?) 



Critical Section Problem 


Consider system of n processes {p 0 , p v ... p n1 } competing to 
access shared data 

Each process has critical section segment of code 

• Process may be changing common variables, updating 
table, writing file, etc 

• When one process in critical section, no other may be in its 
critical section 

Critical section problem is to design protocol to solve this 

Each process must ask permission to enter critical section in 
entry section, may follow critical section with exit section, 
then remainder section 



Critical Section 


General structure of process P. 


do { 


entry section 


critical section 


exit section 


remainder section 
} while (true); 


Solution: Critical Section Problem - 
Requirements 


• Mutual Exclusion 

• If process Pi is executing in its critical section, then no other 
processes can be executing in their critical sections. 

• Progress 

• If no process is executing in its critical section and there exists 
some processes that wish to enter their critical section, then 
the selection of the processes that will enter the critical section 
next cannot be postponed indefinitely. 

• Bounded Waiting 

• A bound must exist on the number of times that other 
processes are allowed to enter their critical sections after a 
process has made a request to enter its critical section and 
before that request is granted. 



Solution: Critical Section Problem - 
Requirements 


• Assume that each process executes at a 
nonzero speed. 

• No assumption concerning relative speed of the 
n processes. 



Solution: Critical Section Problem -- 
Initial Attempt 

• Only 2 processes, PO and PI 

• General structure of process Pi (Pj) 


do { 

entry section 

critical section 
exit section 

remainder section 
} while (true); 

• Processes may share some common variables 
to synchronize their actions. 


Algorithm 1 


• Shared Variables: 

• int turn = 0; 

• (turn == i) means that Pi can enter its critical section 

• Process Pi 

do { 

while (turn == j) ; 

critical section 
turn = j ; 

remainder section 
} while (true) ; 


Satisfies mutual exclusion, but not progress. 



Algorithm 2 


• Shared Variables 

• boolean flag[2]; 

flag[0] = false; flag[1] = false; 

• (flag[i] == true) means that Pi ready to enter its critical section 

• Process Pi 

do { 

flag[i] = true; 

while (flag[j]); 

critical section 
flag[i] = false; 

remainder section 
} while (true) ; 

Can block indefinitely.... Progress requirement not met. 



Algorithm 3 


• Shared Variables 

• boolean flag[2]; 

flag[0] = false; flag[1] = false; 

• (flag[i] == true) means that Pi ready to enter its critical section 

• Process Pi 

do { 

while (flag[j]); 
flag[i] = true; 

critical section 
flag[i] = false; 

remainder section 
} while (true) ; 

Does not satisfy mutual exclusion requirement .... 



Algorithm 4 


• Combined Shared Variables of algorithms 1 and 2 

• Process Pi 

do { 

flag[i] = true; 
turn = j ; 

while (flag[j] && turn == j) ; 

critical section 
flag[i] = false; 

remainder section 
} while (true) ; 

YES!!! Meets all three requirements, solves the critical section 
problem for 2 processes. 

This is called the “Peterson’s solution”. 



Bakery Algorithm 


• Critical section for n processes 

• Before entering its critical section, process receives a 
number. Holder of the smallest number enters critical 
section. 

• If processes Pi and Pj receive the same number, 

• if i < j, then Pi is served first; else Pj is served first. 

• The numbering scheme always generates numbers in 
increasing order of enumeration; i.e. 1,2, 3, 3, 3, 3, 4, 4, 5, 5 



Bakery Algorithm (cont.) 


• Notation - 

• Lexicographic order(ticket#, process id#) 

• (a,b) < ( c,d ) if (a<c) or if ((a=c) and (b < d)) 

• max(ao,....an-i) is a number, k, such that k >=a/ 
for / = 0, . . . , A7- 1 

• Shared Data 

boolean choosing[n]; (all items initialized to false) 
int number[n]; (all initialized to 0) 



Bakery Algorithm (cont.) 


do { 

choosing [i] = true; 

number[i] := max (number [0] , number [1] number [n-1] ) + 1; 
choosing [i] = false; 

for (int j=0; j < n, j++) { 

while (choosing [j ]) ; 

while ((number[j] != 0) && 

( (number [j] , j) < (number [i] , i) ) ; 

} 

critical section 
number [i] = 0; 

remainder section 


} while (true) ; 



Synchronization Hardware 


Many systems provide hardware support for implementing the 
critical section code. 

Solutions based on idea of locking 

• Protecting critical regions via locks 



Synchronization Hardware 


Many systems provide hardware support for implementing the 
critical section code. 

Solutions based on idea of locking 

• Protecting critical regions via locks 
Uniprocessors - could disable interrupts 

• Currently running code would execute without preemption 

• Generally too inefficient on multiprocessor systems 

- Operating systems using this not broadly scalable 

Modern machines provide special atomic hardware instructions 

- Atomic = non-interruptible 

• Either test memory word and set value 

• Or swap contents of two memory words 



Solution to Critical-section Problem Using Locks 


do { 

acquire lock 

critical section 
release lock 

remainder section 
} while (TRUE) ; 



test and set Instruction 


Definition: 

boolean test_and_set (boolean *target) 
{ 

boolean rv = * target; 

* target = TRUE; 
return rv: 

} 

1. Executed atomically 

2. Returns the original value of passed parameter 

3. Set the new value of passed parameter to “TRUE”. 



Solution using test_and_set() 


Shared Boolean variable lock, initialized to FALSE 
Solution: 

do { 

while (test_and_set ( &lock) ) 

; /* do nothing */ 

/* critical section */ 
lock = false; 

/* remainder section */ 


} while (true) ; 



compare and swap Instruction 

Definition: 

int compare_and_swap (int *value, int expected, int new_value) { 
int temp = *value; 

if (*value == expected) 

*value = new_value ; 
return temp; 

} 

1. Executed atomically 

2. Returns the original value of passed parameter “value” 

3. Set the variable “value” the value of the passed parameter “new_value” 
but only if “value” ==“expected”. That is, the swap takes place only under 
this condition. 



Solution using compare_and_swap 

Shared integer “lock” initialized to 0; 

Solution: 

do { 

while ( compare_and_swap ( &lock , 0, 1) != 0) 

; /* do nothing */ 

/* critical section */ 
lock = 0 ; 

/* remainder section */ 


} while (true) ; 



Bounded-waiting Mutual Exclusion with test_and_set 


do { 

waiting [i] = true; 
key = true ; 

while (waiting [i] && key) 

key = test_and_set (Slock) ; 
waiting [i] = false; 

/* critical section */ 
j = (i + 1) % n; 

while ( ( j != i) SS !waiting[j]) 
j = (j + 1) % n; 
if (j == i) 

lock = false; 
else 

waiting[j] = false; 

/* remainder section */ 


} while (true) ; 



Mutex Locks 


Previous solutions are complicated and generally inaccessible 
to application programmers 

OS designers build software tools to solve critical section 
problem 

Simplest is mutex lock 

Protect a critical section by first acquire() a lock then 
release() the lock 

• Boolean variable indicating if lock is available or not 
Calls to acquire() and release() must be atomic 

• Usually implemented via hardware atomic instructions 
But this solution requires busy waiting 

• This lock therefore called a spinlock 



acquire() and release() 

• acquire () { 

while ( ! available) 

; /* busy wait */ 
available = false;; 

} 

• release () { 

available = true; 

} 

• do { 
acquire lock 

critical section 
release lock 

remainder section 


} while (true) ; 



Semaphore 


• Semaphore S - integer variable (non-negative) 

• used to represent number of abstract resources 

• Can only be accessed via two indivisible (atomic) operations 

wait (S): while (S <= 0); 

S-; 

signal (S): S++; 

• P or wait used to acquire a resource, waits for semaphore to 
become positive, then decrements it by 1 

• V or signal releases a resource and increments the semaphore 
by 1 , waking up a waiting P, if any 

• If P is performed on a count <= 0, process must wait for V or 
the release of a resource. 

P Q:“proberen” (to test) ; V() “verhogen” (to increment) in Dutch 



Example: Critical Section for n 
Processes 


• Shared variables 

semaphore mutex; 
initially mutex = 1 

• Process P, 

do { 

wait (mutex) ; 

critical section 
signal (mutex) ; 

remainder section 


} while (true) ; 



Semaphore as a General 
Synchronization Tool 


• Execute B in Pj only after A execute in Pi 

• Use semaphore flag initialized to 0 

• Code: 

Pi Pj 


A 

sign a /(flag) 


wait(flag) 

B 



Problem... 


• Locks prevent conflicting actions on shared data 

• Lock before entering critical section and before accessing shared data 

• Unlock when leaving, after accessing shared data 

• Wait if locked 

• All Synchronization involves waiting 

• Busy Waiting, uses CPU that others could use. This type of lock is 
called a spinlock. 

• Waiting thread may take cycles away from thread holding lock (no one 
wins!) 

• OK for short times since it prevents a context switch. 

• Priority Inversion: If busy-waiting thread has higher priority than thread 
holding lock => no progress! 

• Should sleep if waiting for a long time 

• For longer runtimes, need to modify P and V so that 
processes can block and resume. 



Semaphore Implementation with no Busy waiting 


With each semaphore there is an associated waiting queue 
Each entry in a waiting queue has two data items: 

• value (of type integer) 

• pointer to next record in the list 
Two operations: 

• block - place the process invoking the operation on the 
appropriate waiting queue 

• wakeup - remove one of processes in the waiting queue 
and place it in the ready queue 

typedef struct{ 
int value; 

struct process *list; 

} semaphore ; 



Implementation with no Busy waiting (Cont.) 


wait (semaphore *S) { 

S->value- - ; 

if (S->value < 0) { 

add this process to S->list; 

block ( ) ; 

} 

} 

signal (semaphore *S) { 

S->value++ ; 

if (S->value <= 0) { 

remove a process P from S->list; 

wakeup (P) ; 

} 



Deadlock and Starvation 


Deadlock - two or more processes are waiting indefinitely for 
an event that can be caused by only one of the waiting 
processes. 

• Let S and Q be semaphores initialized to 1 


Po Pi 

wait(S ); wait(Q ); 

wait(Q ); wait(S ); 


s/g^a/ (SJ ; : signal (Q); 

s/'gna/ (Q); s/'gna/ (S); 

Starvation- indefinite blocking. A process may never be 
removed from the semaphore queue in which it is suspended. 



Two Types of Semaphores 


• Counting Semaphore - integer value can range 
over an unrestricted domain. 

• Binary Semaphore - integer value can range 
only between 0 and 1; simpler to implement. 

• Can implement a counting semaphore S as a 
binary semaphore. 



Classical Problems of 
Synchronization 


• Bounded Buffer Problem 

• Readers-Writers Problem 

• Dining-Philosophers Problem 



Bounded Buffer Problem 


• Shared data 

• n buffers, each can hold one item 

• Semaphore mutex initialized to the value 1 

• Semaphore full initialized to the value 0 

• Semaphore empty initialized to the value n 



Bounded Buffer Problem 


• Producer process - creates filled buffers 

do { 

/* produce an item in next_produced */ 

wait (empty) ; 
wait (mutex) ; 

/* add next produced to the buffer */ 

signal (mutex) ; 
signal (full) ; 

} while (true) ; 



Bounded Buffer Problem 


• Consumer process - Empties filled buffers 

do { 

wait (full) ; 
wait (mutex) ; 

/* remove an item from buffer to next_consumed */ 

signal (mutex) ; 
signal (empty) ; 

/* consume the item in next consumed */ 


} while (true) ; 



Discussion 


• ASymmetry? 

• Producer does: P(empty), V(full) 

• Consumer does: P(full), V(empty) 

• Is order of P’s important? 

• Yes! Can cause deadlock 

• Is order of V’s important? 

• No, except that it might affect scheduling efficiency 



Readers- Writers Problem 



• Two classes of users: 

• Readers - never modify database 

• Writers - read and modify database 

• Is using a single lock on the whole database sufficient? 

• Like to have many readers at the same time 

• Only one writer at a time 


Readers- Writers Problem 


• Shared Data 

• Data set 

• Semaphore rw_mutex initialized to 1 

• Semaphore mutex initialized to 1 

• Integer read_count initialized to 0 

• The structure of a writer process 

do { 

wait (rw_mutex) ; 

/* writing is performed */ 

signal (rw_mutex) ; 

} while (true) ; 



Readers- Writers Problem 


• The structure of a reader process 

do { 

wait (mutex) ; 
read_count++ ; 
if (read_count == 1) 

wait (rw_mutex) ; 

signal (mutex) ; 

/* reading is performed */ 


wait (mutex) ; 

read count--; 

if (read_count == 0) 

signal (rw_mutex) ; 

signal (mutex) ; 

} while (true) ; 



Dining-Philosophers Problem 



• Philosophers spend their lives alternating thinking and eating 

• Don’t interact with their neighbors, occasionally try to pick up 2 
chopsticks (one at a time) to eat from bowl 

• Need both to eat, then release both when done 

• In the case of 5 philosophers 

• Shared data 

- Bowl of rice (data set) 

- Semaphore chopstick [5] initialized to 1 


Dining Philosophers Problem 


• The structure of Philosopher /: 

do { 

wait (chopstick[i] ); 
wait (chopStick[ (i + 1) % 5] ); 

II eat 

signal (chopstick[i] ); 
signal (chopstick[ (i + 1) % 5] ); 

II think 

} while (TRUE); 

• What is the problem with this algorithm? 



Dining Philosophers Problem 


• Deadlock handling 

• Allow at most 4 philosophers to be sitting simultaneously at the table. 

• Allow a philosopher to pick up the forks only if both are available 
(picking must be done in a critical section. 

• Use an asymmetric solution -- an odd-numbered philosopher picks 
up first the left chopstick and then the right chopstick. Even-numbered 
philosopher picks up first the right chopstick and then the left 
chopstick. 



Problems with Semaphores 


Incorrect use of semaphore operations: 

• signal (mutex) .... wait (mutex) 

• wait (mutex) ... wait (mutex) 

• Omitting of wait (mutex) or signal (mutex) (or both) 
Deadlock and starvation are possible. 



Monitors 


• A high-level abstraction that provides a convenient and effective 
mechanism for process synchronization 

• Abstract data type, internal variables only accessible by code within the 
procedure 

• Only one process may be active within the monitor at a time 

• But not powerful enough to model some synchronization schemes 

monitor monitor-name 
{ 

// shared variable declarations 
procedure Pi (...) { ... . } 

procedure Pn (...) { } 

Initialization code (...) { ... } 

} 

} 



Schematic view of a Monitor 






Condition Variables 


condition x, y; 

Two operations are allowed on a condition variable: 

• x . wait () - a process that invokes the operation is 
suspended until x . signal ( ) 

• x . signal ( ) - resumes one of processes (if any) that 
invoked x . wait () 

- If no x . wait ( ) on the variable, then it has no effect on the 
variable 



Monitor with Condition Variables 






Condition Variables Choices 


If process P invokes x . signal ( ) , and process Q is suspended in 
x . wait ( ) , what should happen next? 

• Both Q and P cannot execute in parallel. If Q is resumed, then P 
must wait 

Options include 

• Signal and wait - P waits until Q either leaves the monitor or it 
waits for another condition 

• Signal and continue - Q waits until P either leaves the monitor or it 
waits for another condition 

• Both have pros and cons - language implementer can decide 



Monitor Solution to Dining Philosophers 


monitor DiningPhilosophers 

{ 

enum { THINKING; HUNGRY, EATING) state [5] ; 

condition self [5] ; 

void pickup (int i) { 

state [i] = HUNGRY; 
test (i ) ; 

if (state[i] != EATING) self [i] . wait ; 

} 

void putdown (int i) { 

state [i] = THINKING; 

/ / test left and right neighbors 
test ( (i + 4 ) % 5 ) ; 
test ( (i + 1 ) % 5 ) ; 


} 



Solution to Dining Philosophers (Cont.) 


void test (int i) { 

if ( (state [ (i + 4) % 5] != EATING) && 

(state [i] == HUNGRY) && 

(state [ (i +1) % 5] != EATING) ) { 

state [i] = EATING ; 
self [ i ]. signal () ; 

} 


} 


initialization code ( ) { 

for (int i = 0; i < 5; i + +) 
state [i] = THINKING; 


} 



Solution to Dining Philosophers (Cont.) 


Each philosopher / invokes the operations pickup ( ) and 
putdown () in the following sequence: 

DiningPhilosophers .pickup (i) ; 
EAT 

DiningPhilosophers .putdown (i) ; 


No deadlock, but starvation is possible 



Monitor Implementation Using Semaphores 


• Variables 

semaphore mutex; // (initially = 1) 
semaphore next; // (initially = 0) 
int next_count = 0 ; 

• Each procedure F will be replaced by 

wait (mutex) ; 

body of F; 

if (next_count > 0) 
signal (next) 
else 

signal (mutex) ; 

• Mutual exclusion within a monitor is ensured 



Monitor Implementation - Condition Variables 


For each condition variable x, we have: 

semaphore x_sem; // (initially = 0) 
int x_count = 0 ; 

The operation x.wait can be implemented as: 

x_count++ ; 
if (next_count > 0) 
signal (next) ; 
else 

signal (mutex) ; 
wait(x_sem) ; 
x count--; 



Monitor Implementation (Cont.) 


The operation x. signal can be implemented as: 

if (x_count >0) { 

next_count++ ; 
signal (x_sem) ; 
wait (next) ; 
next count--; 


} 



